This question is a bit obvious, but it is one which I had no specific answer for when I put my patent together.
When I conceived the Clique Space(TM) data model, I took as an article of some speculative faith, the premise that I could work out the technical considerations of how this model would be used to realise the mechanism that actually allows one Agent Device to exchange information with one or more others, as well as how one Agent Device exchanges Clique Space Element information for external device state information. I had hypothesised that mechanisms would emerge as a result of the deliberations necessary to get from the concept recorded in the patent, to its implementation recorded in code.
I envisaged that perhaps some degree of similarity between Clique Spaces and biological nervous systems would emerge, and indeed, this appears to have happened in at least one example: the emergence of the logical synapse necessary to open a channel for exchange between two Agent Devices. Although the synapse is reasonably stable, my current deliberations will have an impact on this mechanism because the changing form of the information exchange will also change the way Agent Devices engage and disengage, forming and disbanding bipartite Cliques which represent these synapses. Although I had thought the synapse might emerge as far back as when I put the patent together, this hypothetical mechanism lacked the implementation detail that exists currently; it is anticipated that some of this current detail will have been discarded and replaced before one can confidently say the synapse mechanism exhibits its final form.
The wider deliberation of the mechanism needed to get collections of Agent Devices, being members of a Clique, to communicate the changing state of their Elements amongst each other have brought me to yet other limits of my intellectual capacity as it was when I put the patent together. I feel that the implementation has evolved to a point where, since stabilising the implementation of the properties mechanism
discussed in my last post - an act in itself which has pointed me the
way to the promise of an answer - I now appear prepared to start replacing at least some of this faith with some reason.
At least at a purely logical level, I think my progression from this point may provide some interesting insight into how a biological nervous system recruits and coordinates its individual neurons in the performance of some act instigated by and for the organism as a whole. Such a mechanism would exhibit hierarchical and executive command and control structures, but would also simultaneously appear to self-assemble based on some form of consensus between neurons (Agent Devices) in accordance with the varying capacity of each neuron to participate. Hence, it would be very hard in any Clique Space (indeed, as it might be demonstrated in any neural system) to point to a single Agent Device as being ultimately responsible for the conduct of any Clique Space as a whole.
Whether synthetic or biological, any such system would definitely require some systematic form of message propagation. It is to this mechanism that my deliberations appear once more to turn. I have some general ideas which I hope to test. For instance, as I explained in a previous post, I see the necessity for Agent Devices to have two Cliques model a single collaboration between a collection of devices, whether these devices are Agent Devices being members of a Clique space, or a collection of devices participating in a collaboration defined by a Media Profile type external to the Clique Space implementation.
The first Clique primarily models what is actually going on in the collaboration; it gives Clique Space a sense of the collaboration's reason for existence, and to the characteristics of its member Participants in accordance to the ability of the Clique's medium to report the collaboration's activity. The second Clique is used to model which Agent Devices have a stake in knowing what is going on in the first Clique by virtue of the fact that any member Participants of this Agent Collaboration's Clique share a combination of the following three relationships with the first Clique: 1. that these Agent Devices are connected to the devices who's collaborative activity is being modelled as participants of the first Clique, or 2. that these Agent Devices are connected to a View or persistence mechanism-enabled devices viewing or persisting activity of the first Clique, and optionally, may be capable of controlling the first Clique, or 3. that these Agent Devices may be acting as relay devices, permitting propagation of Element state from Agent Devices of the first two types located in one physical location to those located in another, but for which the Agent Devices at the first location share no synapses with those at the second; perhaps a bit like a corpus callosum.
This dual-Clique scheme seems a reasonable way to propagate messages amongst relevant Agent Devices, but this mechanism does not include View or persistence devices, because they are not Agent Devices, and hence lack the mechanics necessary to participate in an Agent Collaboration. These type of external devices require another protocol to receive and process Element state information, even if these devices use the same message transport vehicle - the component transmitter, discussed in the previous entry - used in the Agent Collaboration.
It might be interesting at this point to consider how it is a designed intent that the Media Profile Element fits the bill for encoding the protocol for any collaboration type so an Agent Device can receive, process, and control device state. The information content generated by any device may be augmented with Clique Space information in the given device's media in accordance with the Media Profile through which a Connection has been established. The general concept of the Media Profile is used to describe the parameters that a specific protocol will accept. Specifically, the protocols which describe the operational parameters of 1. the Agent Collaboration, and 2. the administrator client, are exposed through Media Profiles like any other protocols. Hence, the Agent Collaboration's protocol is exposed inside the mechanism that implements this protocol by an Agent Collaboration Media Profile so the Agent Collaboration's activity, modelled as a Clique, can be Viewed, persisted, or controlled by an administrator client or any external device which possesses such a capability.
Hence, the Agent Devices have their Agent Collaboration Media Profile. This Media Profile provides the mechanism that realises the second Clique necessary for the dual-Clique propagation scheme. A Media Profile for the administrator client will be fashioned that facilitates the component exchange scheme between an Agent Device and a View or persistence enabled external device. Both the administrator client's component exchange and the Agent Device's dual-Clique schemes will use the common component propagation and exchange mechanism - the component transmitter.
The component transmitter mechanism currently looks like the ideal candidate for the administrator client component exchange scheme as it is for the Agent Device's dual-clique scheme. This is the intention for the design of the component transmitter mechanism; this mechanism replaces the failed Element precis mechanism for the Agent Collaboration, and a promising, but demonstrably inadequate Element projection mechanism for the administrator client. Both the failure of the Element precis and the inadequacy of the Element projection mechanisms prompted me to look to the component transmitter mechanism as a sufficient and flexible alternative candidate for a solution to the question of message propagation.
Monday, September 3, 2012
Monday, August 27, 2012
Elements and components; components and properties; properties and transmitters; transmitters and quanta; quanta and components; components and components; components and transmitters; transmitters and Elements; Elements and properties; properties and components... crikey
This blog entry is about Clique Space (TM) implementation progress.
It's been a while since my last post. I've been working hard on the implementation; working on replacing the precis and the projection mechanisms with a mechanism I hope will be able to be used by both Agent Devices and View enabled devices like the administrator client. Every time I feel I'm getting a handle on the implementation, I seem to stumble onto a new phenomenon which, upon closer inspection, appears to open up a set of hitherto unanticipated set of implications. I shake my head when this happens repetitively; I hope I am sufficiently sane to carry this proof-of-concept to some type of a demonstrable conclusion within the next year or two.
So, to the deliberation at hand...
The Element - component relationship is recursive, and different components can be represented to an Element as a mandatory scalar (the Element's identifier), an optional scalar (a Connection's Media Profile), or even as members of a set (an Identity's Connections). Properties promise to allow a device to manage its knowledge of Elements. The properties mechanism enables the separation of Elements from the Elements' components. This has one particular advantage: an Element, who's components can be naturally categorised into properties, can be implemented as a set of properties. The properties mechanism hence promises any device a relatively simple and reliable way to manage the device's knowledge of an Element's state and life-cycle.
Travelling along this line of rationale warranting the properties mechanism, I encountered some problems. How does one transmit an Element's components? What if Limiting Constraint affinity prevents partial transmission of a collection of components contained in a property? What type of complex logic would permit a "property changed" message to be transmitted? Can we just get away with a binary "component added" and "component removed" logic?
Additionally, I realised that I could simplify the implementation of the properties mechanism if I were to permit a general relationship between a property and its component(s): whether scalars or sets, properties can have a default collection relationship to an Element's components. This default collection aspect of properties is convenient for the requirement that Elements contain a set of properties, but it also compounds the problem of transmission.
So, an Element is a container of properties. Properties are a mechanism that categorises an Element's components. Properties may have a mandatory or optional singular (scalar) or set (or even, perhaps associative map) relationship with the components they categorise, but, to allow all properties a single way to access their components, all properties extend a base property class which contains an associative map of components. Hence, in this relationship, it appears necessary to acknowledge a pattern underlying the properties mechanism: an Element is a collection of collections of components.
This answer appears to have underscored the need to answer the question of component transmission with perhaps another mechanism. To do this, it appears convenient (if not absolutely necessary... but I think it is this too) that components, whether existing in a property as a scalar or as a member of a collection, are transmitted from one device to another, as singular pieces of atomic information, or to perhaps without warrant, steal a term from physics: quanta. The answer regarding the question of binary logic appears to be that we can get all we need simply by implementing add and remove logic; no change logic is necessary.
So, the solution to the question of property transmission...
A transmitter is an algorithmic vehicle which contains a quantum. A quantum may be a property's component if the component is a data type capable of serialisation, or it may be a serialisable copy of the component if the component cannot itself be serialised. One, and only one quantum is transmitted in a transmitter; a quantum represents the minimum amount of information representing a particular component.
So, why the transmitter? Can't a device just transmit and receive quanta? The answer is that the transmitter appears to use something akin to the visitor OO design pattern so that a device can understand why the quantum was transmitted. The transmitter mechanism is an abstract class of which there are two concrete extensions: one to deal with component addition and the other to deal with component removal.
When the agent device receives the relevant transmitter extension, it calls a method declared in the base transmitter and implemented in the relevant extension which in turn calls the add or remove component method on the quantum, doing whatever is intuitive to create or remove the corresponding component on the Agent Device which has received the transmitter. Hence, the receiving device uses the power of polymorphism given to a quantum's implementation to determine how this quantum affects the state of the corresponding component on the Agent Device.
This solution appears to be the simplest available. Exceptions can be generated for any transmitters that attempt to add a component which the receiving device currently knows of, or to remove a component which the receiving device doesn't know of, which appears to be almost all the questions of transmission answered. There lurk nearby, other phenomena which I have admired from afar; these phenomena appear to suggest other puzzles, but I'm hoping these puzzles are easier to solve.
It's been a while since my last post. I've been working hard on the implementation; working on replacing the precis and the projection mechanisms with a mechanism I hope will be able to be used by both Agent Devices and View enabled devices like the administrator client. Every time I feel I'm getting a handle on the implementation, I seem to stumble onto a new phenomenon which, upon closer inspection, appears to open up a set of hitherto unanticipated set of implications. I shake my head when this happens repetitively; I hope I am sufficiently sane to carry this proof-of-concept to some type of a demonstrable conclusion within the next year or two.
So, to the deliberation at hand...
The Element - component relationship is recursive, and different components can be represented to an Element as a mandatory scalar (the Element's identifier), an optional scalar (a Connection's Media Profile), or even as members of a set (an Identity's Connections). Properties promise to allow a device to manage its knowledge of Elements. The properties mechanism enables the separation of Elements from the Elements' components. This has one particular advantage: an Element, who's components can be naturally categorised into properties, can be implemented as a set of properties. The properties mechanism hence promises any device a relatively simple and reliable way to manage the device's knowledge of an Element's state and life-cycle.
Travelling along this line of rationale warranting the properties mechanism, I encountered some problems. How does one transmit an Element's components? What if Limiting Constraint affinity prevents partial transmission of a collection of components contained in a property? What type of complex logic would permit a "property changed" message to be transmitted? Can we just get away with a binary "component added" and "component removed" logic?
Additionally, I realised that I could simplify the implementation of the properties mechanism if I were to permit a general relationship between a property and its component(s): whether scalars or sets, properties can have a default collection relationship to an Element's components. This default collection aspect of properties is convenient for the requirement that Elements contain a set of properties, but it also compounds the problem of transmission.
So, an Element is a container of properties. Properties are a mechanism that categorises an Element's components. Properties may have a mandatory or optional singular (scalar) or set (or even, perhaps associative map) relationship with the components they categorise, but, to allow all properties a single way to access their components, all properties extend a base property class which contains an associative map of components. Hence, in this relationship, it appears necessary to acknowledge a pattern underlying the properties mechanism: an Element is a collection of collections of components.
This answer appears to have underscored the need to answer the question of component transmission with perhaps another mechanism. To do this, it appears convenient (if not absolutely necessary... but I think it is this too) that components, whether existing in a property as a scalar or as a member of a collection, are transmitted from one device to another, as singular pieces of atomic information, or to perhaps without warrant, steal a term from physics: quanta. The answer regarding the question of binary logic appears to be that we can get all we need simply by implementing add and remove logic; no change logic is necessary.
So, the solution to the question of property transmission...
A transmitter is an algorithmic vehicle which contains a quantum. A quantum may be a property's component if the component is a data type capable of serialisation, or it may be a serialisable copy of the component if the component cannot itself be serialised. One, and only one quantum is transmitted in a transmitter; a quantum represents the minimum amount of information representing a particular component.
So, why the transmitter? Can't a device just transmit and receive quanta? The answer is that the transmitter appears to use something akin to the visitor OO design pattern so that a device can understand why the quantum was transmitted. The transmitter mechanism is an abstract class of which there are two concrete extensions: one to deal with component addition and the other to deal with component removal.
When the agent device receives the relevant transmitter extension, it calls a method declared in the base transmitter and implemented in the relevant extension which in turn calls the add or remove component method on the quantum, doing whatever is intuitive to create or remove the corresponding component on the Agent Device which has received the transmitter. Hence, the receiving device uses the power of polymorphism given to a quantum's implementation to determine how this quantum affects the state of the corresponding component on the Agent Device.
This solution appears to be the simplest available. Exceptions can be generated for any transmitters that attempt to add a component which the receiving device currently knows of, or to remove a component which the receiving device doesn't know of, which appears to be almost all the questions of transmission answered. There lurk nearby, other phenomena which I have admired from afar; these phenomena appear to suggest other puzzles, but I'm hoping these puzzles are easier to solve.
Saturday, August 4, 2012
Sensory -> Motor :: client collaboration's Clique -> Agent Collaboration's Clique
Don't get too hopeful, but this mechanism may be the final necessary functional addition to the implementation. Once implemented, the concept might be proven.
In this entry, I briefly covered what appears to be a phenomenon which emerged as a side-effect of the progress to a functional implementation: one appears to require two Cliques in order to properly model and control collaborative activity in Clique Space(TM). Again, this mechanism arises due to the necessity of Clique Space being able to construct an environment in which a self can be extended into cyberspace; an act which must necessarily be self-referential. This mechanism might appear to be analogous to sensory and motor homunculi - a feature of complex nervous systems such as our own.
The mechanism appears to operate in the following generic way.
Clique Space siphons the state of connected devices and measures this raw device state against Limiting Constraint characteristics of the corresponding Clique's Participants; this Clique is the client collaboration Clique which models the external collaboration. This Clique, its Participants, the Participants' Limiting Constraints, and other Participants' components and can be viewed or persisted as Limiting Constraint affinity permits by any individual, possessing sufficient constraint affinity, regardless of whether they are participating in the external collaboration or not. Hence, this Clique might be seen as a type of sensory homunculus because it gives an individual who can view the collaboration as a Clique, a sense of what is going on in the collaboration the Clique is modelling.
The Agent Collaboration's Clique might be likened to a motor homunculus. This Clique permits Participants' modelled state changes to be distributed throughout the Agent Devices which are siphoning the state of the devices participating in the external collaboration. In addition to the participating devices, Agent Devices which siphon and serve devices which can view, or persist, or even control device activity are also Participants if any connected devices with these capabilities, having sufficient Limiting Constraint affinity, intend to view, persist or control activity of the client collaboration's Clique.
There appears to be one specific exception.
The Agent Collaboration's Clique is a model of itself. This model is completely trivial and unsustainable without a client collaboration's Clique; modelling one Agent Collaboration's Clique with another promotes infinite regress. Viewing or persisting the activity in an Agent Collaboration's Clique might be thought of as acts of philosophical introspection. Perhaps attempting to control the Agent Collaboration's Clique might be seen as a kind of evil, and may be prohibited in a Clique Space administered by individuals who may find attempts to directly control an Agent Collaboration's Clique ethically questionable. Taking control of an Agent Collaboration's Clique would be like someone taking control of your own limbs through stimulating various areas of the motor homunculus of your own nervous system; you may find your body behaving in strange ways, and you might be further confused as to the intentions you had when performing these actions.
The reader is not seeing things. The term "client collaboration" is not capitalised whereas the term "Agent Collaboration" is.This is because the client collaboration, although mentioned in the patent, was considered by me as more of a context (a client collaboration as the collaboration going on in the device manufacturer's media and being modelled as a Clique by virtue of the fact that each of the member devices' state, connected to Clique Space through zero or more Agent Devices, is, provided the external device is connected to at least one Agent Device, being siphoned off by these Agent Devices and replicated in the Clique) than as anything structurally relevant to Clique Space.
This perspective can be contrasted with the Agent Collaboration, which was, at the time the patent was published, thought to have structural relevance even if the Agent Collaboration is perhaps more refined now (an Agent Collaboration is any set of Agent Devices involved in both siphoning state from the devices involved in the client collaboration and serving the view/persistence/control devices interested in this same client collaboration) than it was when the patent was published (an Agent Collaboration being merely the model of the set of Agent Devices participating in a particular Clique Space - what can now be considered a client collaboration in the mechanism disclosed in this entry). Maybe in the future I'll decide to capitalise the term Client Collaboration... maybe that time will be as soon as I implement the mechanism I have disclosed here.
In this entry, I briefly covered what appears to be a phenomenon which emerged as a side-effect of the progress to a functional implementation: one appears to require two Cliques in order to properly model and control collaborative activity in Clique Space(TM). Again, this mechanism arises due to the necessity of Clique Space being able to construct an environment in which a self can be extended into cyberspace; an act which must necessarily be self-referential. This mechanism might appear to be analogous to sensory and motor homunculi - a feature of complex nervous systems such as our own.
The mechanism appears to operate in the following generic way.
Clique Space siphons the state of connected devices and measures this raw device state against Limiting Constraint characteristics of the corresponding Clique's Participants; this Clique is the client collaboration Clique which models the external collaboration. This Clique, its Participants, the Participants' Limiting Constraints, and other Participants' components and can be viewed or persisted as Limiting Constraint affinity permits by any individual, possessing sufficient constraint affinity, regardless of whether they are participating in the external collaboration or not. Hence, this Clique might be seen as a type of sensory homunculus because it gives an individual who can view the collaboration as a Clique, a sense of what is going on in the collaboration the Clique is modelling.
The Agent Collaboration's Clique might be likened to a motor homunculus. This Clique permits Participants' modelled state changes to be distributed throughout the Agent Devices which are siphoning the state of the devices participating in the external collaboration. In addition to the participating devices, Agent Devices which siphon and serve devices which can view, or persist, or even control device activity are also Participants if any connected devices with these capabilities, having sufficient Limiting Constraint affinity, intend to view, persist or control activity of the client collaboration's Clique.
There appears to be one specific exception.
The Agent Collaboration's Clique is a model of itself. This model is completely trivial and unsustainable without a client collaboration's Clique; modelling one Agent Collaboration's Clique with another promotes infinite regress. Viewing or persisting the activity in an Agent Collaboration's Clique might be thought of as acts of philosophical introspection. Perhaps attempting to control the Agent Collaboration's Clique might be seen as a kind of evil, and may be prohibited in a Clique Space administered by individuals who may find attempts to directly control an Agent Collaboration's Clique ethically questionable. Taking control of an Agent Collaboration's Clique would be like someone taking control of your own limbs through stimulating various areas of the motor homunculus of your own nervous system; you may find your body behaving in strange ways, and you might be further confused as to the intentions you had when performing these actions.
The reader is not seeing things. The term "client collaboration" is not capitalised whereas the term "Agent Collaboration" is.This is because the client collaboration, although mentioned in the patent, was considered by me as more of a context (a client collaboration as the collaboration going on in the device manufacturer's media and being modelled as a Clique by virtue of the fact that each of the member devices' state, connected to Clique Space through zero or more Agent Devices, is, provided the external device is connected to at least one Agent Device, being siphoned off by these Agent Devices and replicated in the Clique) than as anything structurally relevant to Clique Space.
This perspective can be contrasted with the Agent Collaboration, which was, at the time the patent was published, thought to have structural relevance even if the Agent Collaboration is perhaps more refined now (an Agent Collaboration is any set of Agent Devices involved in both siphoning state from the devices involved in the client collaboration and serving the view/persistence/control devices interested in this same client collaboration) than it was when the patent was published (an Agent Collaboration being merely the model of the set of Agent Devices participating in a particular Clique Space - what can now be considered a client collaboration in the mechanism disclosed in this entry). Maybe in the future I'll decide to capitalise the term Client Collaboration... maybe that time will be as soon as I implement the mechanism I have disclosed here.
Thursday, July 19, 2012
Things coming together.
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.
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.
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...
Subscribe to:
Posts (Atom)