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.

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.