Rolons and IPs

[Ged Byrne]

Hi Bill,

I've be reading through the Agile Wiki and find it fascinating.  

I'd love to find the common area between the two models: Rolonics and FBP.

Rolonics is a very high level theory with the goal of addressing the problem that "there is no general, high-level model for software development.In the last 50 years there has been a lot of progress in the understanding of systems of systems, but this work has remained largely obscure. The result is that there is no way to design and implement a system (or service) with any assurance that it can interoperate with other systems. "

FBP is a low level approach that the discoverer found to be valuable becuase it provided "a single application view that spans the range from mini to maxi."

Paul, 

would you feel comfortable in describing FBP as  a "general, high-level model for software development for the creation of a system of systems that provides the assurance that all systems may interoperate with all other systems?"

For this I will define a system as a graph of components where each component is either a sub-system or a single processor?

Bill,

Can I trouble you for the answer to two quesitons?  If you can find common ground with other projects you can cut your work short by decades.

1. What are the difference between a Rolnd and an IP?  Could you class each difference in the following manner:
1. Gap: a feature lacking from IP that they could be extended to support.
2. Block: a feature that you believe IP could never support.
2. How are Rolon's implemented in JActor?

I appreciate that it is possible that there might be a single block that makes Rolons and IPs completely incompatible.

I also appreciate that other elements of FBP, such as a processor, may also be Rolon's of a different type, but for now can we just focus on the IP?

Thanks, 

Ged

ps.  You really need to sort this phrase out from http://sourceforge.net/apps/trac/agilewiki/

"And vagina are difficult to organize is too simplistic to be useful."

On 7 May 2012 16:58, William la Forge <lafo...@gmail.com> wrote:

[...]

I used to talk about Rolonics Theory a lot. But it is really difficult to grasp, because it is so damn intuitively obvious--once you can hear the sound of one hand clapping as it were. And besides being difficult to implement with current technology, it always sounds like smoke & mirrors when I talk about it.

I've had a lot of partial successes over the years, but as I said before too much of the code was never finished. And now I'm implementing AND FINISHING the parts as I go. But it is going to take years.

The motivation for JActor, JID and the new JFile projects are very low-level parts of AgileWiki. I'm implementing them because I need them, though they may have a further impact beyond the AgileWiki project. My hope, anyway.

My short term goal right now is an in-memory database. Then to expand it to a COW-based hierarchical database. And then integrate it with a web server. And then slowly to reintroduce Rolonics in the form of a Wiki, something like http://wagn.org/

Bill

On Mon, May 7, 2012 at 7:34 PM, Paul Morrison <paul.m...@rogers.com> wrote:

[...] 

Later on, I realized that, even more, it improved maintainability (or as Ralf calls it, evolvability); then still later, as a way of taking advantage of multiple processors, and in fact as a single application view that spans the range from mini to maxi :-)  

[...] 

Regards,

Paul

[William la Forge]

Ged,

I rolled that page back about 20 versions. Also tightened permissions.

It is an old doc. I haven't talked about web 3.0 for several years now.

OK, mostly I've been writing code rather than pontificating so much. But I'm glad you enjoyed it. Take another look now that I've removed all those spurious changes.

Can't say I have any gaps or blocks. Most of the time I don't think of things from the perspective of flow based programming, though the transaction logger I'm almost ready to work on is a definite exception!

As for implementing Rolons, I need to climb up a few levels of abstraction. Er, as composites of actors. Gosh, it has been a long time since I've thought about this stuff. And a few more years before I  need to start thinking about it again as well.

Bill

[Paul Tarvydas]

http://laforge49.blogspot.ca/2009/02/rolon-basics.html

For discussion, here's my (probably inadequate) understanding of rolons:

Rolons are structs (or objects) that contain the following fields

headline
context
names
journals
realms
useraccounts
relations
accesscontrol
usergroups

which form kind of a distributed/able file system.

There's a unique UUID for every rolon, plus a more humane way to reference them using "/" syntax. (I think the mapping between UUID's and names is stored locally in each rolon, iiuc).

The web3/w3c/semantic-web connection is the "relations" field.

A relation is a triple (n-triple) - relation, subject, object.

Code is provided via "plugins", but I haven't sussed out what these are. Rolons can be implemented as XML, so maybe plugins are pieces of embedded code or references to external code.


My $0.02:

Structs (objects) are a bad idea - they lead to premature design calcification.

Everything should be a triple, e.g.

(rolon UUID0 nil)
(headline UUID0 "...")
(context UUID0 (UUID1, UUID2, ...))
(names UUID0 (UUID-to-name-triple-1, UUID-to-name-triple-2, ...))
etc, etc.

Code then attaches itself, like a barnacle, to the bag of triples (a "factbase" in my parlance) and sifts through the facts, performing actions when appropriate.

Or, as I did in VSH, the factbase itself becomes an IP and is passed through a chain of components. Each component has the option to insert new (more semantically refined) triples or deleting triples before passing the factbase along.

As one designs a system, one often "discovers" new ideas about the data - "if I had this field, then the job would be easier at this point". With a factbase confined to contain strict triples, adding "fields" is as easy as inserting new triples. One can even strip out the new fields downstream as an "optimization".


Code should be composable (i.e. FBP).

Data/knowledge should be composable (i.e. triples in factbases).


Clarifications and comments welcome.

pt

[Paul Morrison]

This makes sense to me! I am curious what Bill has to say about your
description of rolons and/or about your suggested enhancement/refinement
of the concept.

Henri, is there a connection here with IKS?

Regards,

Paul

[William la Forge]

Well done and pretty close.

Each Rolon has a set of properties, which is where things like headline are.

Relations are a bit more complicated. You can attach data (labels) to either side of a relationship. This is where names are attached of the parent/child relationship.

Rolons are composed of elements and elements are composed in turn, or were anyway. I'm thinking now that the elements of a rolon would map to JID actors, but I haven't gotten that far yet with JActor. (Each element also had a set of properties, but that may be overkill.)

One special relationship was the parent/child relationship, which is a many-to-many but which formed a bush structure, so there was a single root. All rolons had to be tied into the same structure.

Now you've got what would be a vocabulary for each rolon. I.E. Wiki words. This consists, at a minimum, of the names of all a rolon's ancestors and their immediate decendents. The applicable context relationship then is used to extend this vocabulary in various ways.

Now you turn the whole thing into an incremental inference engine. The key here is that the vocabulary is used to restrict the working set for inferences being considered for each rolon. (I only got so far in one version to have a non-incremental inference engine working, which is obviously not at all scalable. This was about 6 years ago or so when I was working in Python.)

Bill

[William la Forge]

After loosing funding from Norm, I switched from Python to Java (Python was too slow). I was working at the time as a staff engineer for Sun Microsystems and got permission to work on AgileWiki as an open source project.

I developed a versioning database and implemented a privacy model using relations. On top of that I integrated a mail client and a wiki. Worked pretty well. You could organize your email and share items on the wiki.

Took a holiday while working at Fiorano. Then got a client in Kuwait, switched to Scala and worked on a version that could scale across multiple systems and work as a document repository as well as a wiki.

Now I'm back to Java with a dual focus: performance and stability. So I'm doing things piecemeal and doing my best to finish each piece as best I can before working on the next. I'm going for vertical (single box) scalability and for now avoiding the complex issues of horizontal (multiple box) scalability.

Bill

[Paul Morrison]

On 08/05/2012 2:09 AM, Ged Byrne wrote:

would you feel comfortable in describing FBP as  a "general, high-level model for software development for the creation of a system of systems that provides the assurance that all systems may interoperate with all other systems?"

For this I will define a system as a graph of components where each component is either a sub-system or a single processor?

Hi Ged,

It's probably a function of my age and years in the business, but the first phrase just makes me very nervous :-)  I think I saw it somewhere in the Agilewiki documentation, but I'd be suspicious of anything that makes this claim, and certainly wouldn't claim it for FBP.  That said, I do believe that FBP provides a consistent view that scales up from a pretty low level, like some types of hardware, to levels beyond computer applications, such as e.g. the flow of documents within a department.  Would a network of systems all running FBP be a "system of systems"?!  However, pragmatically, we have found that it makes sense to have procedural components as the lowest implementation level - it's probably not essential theoretically - it's just easier for humans...

A sizable chunk of these years were spent on trying to come up with standards - for me that's like trying to push a string uphill, and just as frustrating :-)    A few years ago, I did some work on "business units" - http://www.jpaulmorrison.com/datatyps.shtml - and even there you get into complexities on top of complexities.  There is an interesting discussion of standards in http://geekdoctor.blogspot.com/2009/05/personal-reflection-on-standards.html ,  which also refers positively to UCUM - http://unitsofmeasure.org/ -  which has been going for some years, and which I have been peripherally involved with for quite a few of them.

I may be wrong, but the goal of FBP seems to me to be different from that of Agilewiki - if I understand the latter correctly, it seeks to model the real world, whereas FBP is oriented towards building automated applications.  Various writers have suggested that FBP could model the human brain, or an ant colony, but I confess that I am having trouble visualizing where the two approaches meet.  This is also probably why Bill and I are having trouble coming up with an application area where the two approaches could be compared  cleanly. 

Finally, is AgileWiki an attempt at a de facto standard?  If not, I don't see how it can claim to allow all systems to interoperate with all other systems.  If it is, then surely there will have to be widespread acceptance - or maybe the claim is that it can describe anything, in which case performance will be an issue, surely?  Interestingly, the first comment on the cited article mentions ESBs as pragmatic solution to the communication problem - that would seem to a better match with FBP... :-)

I may have totally misunderstood the issue here :-\

Paul

[Ged Byrne]

Hi Paul,

I took the idea of Rolons to be a logical concept that could be used to describe any system.  It should, therefore, be able to describe FPB.  I was hoping to find some commonality by describing the FPB in terms of Rolons.

I think it was me that totally misunderstood.

Regards, 

Ged

On 10 May 2012 20:48, Paul Morrison <paul.m...@rogers.com> wrote:

[...]

[Paul Morrison]

Or maybe me :-)  I don't really have a picture of what Rolons are.  I was assuming that they are a way to build applications - based on what I had gleaned about JActor...  But if they are in fact a description mechanism, how do you then use the description?

--
http://jpaulmorrison.blogspot.com/

[Paul Morrison]

I am getting a bit of a clearer picture - please correct me if I'm way off base.  Rolons are starting to seem to me like an example of declarative programming, where you describe some subset of reality and then give it a goal, and say "go".   This feeling underlies a lot of the early functional stuff.  I remember Strachey describing a functional program as a whole bunch of function definitions, and then you say "print f(x)", and it runs (that was about 50 years ago, of course)!  For me, Prolog has that kind of feeling too - and I note Bill talks about an incremental inference engine, so I am maybe not too far off the mark...  IPL/V was an early competitor of LISP and seemed to be oriented around describing reality (LISP won).

The network definitions of FBP should in that case be a sort of subset of Rolons (or whatever network definitions are called in this technology).  If I'm right, then can we have "active" and "passive" Rolons, roughly corresponding to processes and IPs...?   Maybe "activity" could be thought of as a variable attribute of all "things", with rocks (IPs) having very little, and animals (processes) rather a lot?  Trees are in the middle...  Now, a lot of systems treat code as data, e.g. any compiler, but there has to be some "vital spark" to start the whole thing going - or maybe it's just the programmer hitting the "go" button...

It would be nice if FBP and Rolons have come to somewhere near the same place - but arriving from totally different directions... :-) 

[William la Forge]

Paul, 

There are a lot of claims for Rolonic Theory that I am uncomfortable with too, especially in light of the difficulties I've had with the implementations.

I also agree that it is great to approach a common goal from more than one direction, especially if each approach that is taken helps illuminate the difficulties that need to be addressed.

My own feeling on the matter now is to take the conservative approach and implement things piecemeal with the hope that the path I take has value even if the final destination does not. Though I am still convinced that the idea of a powerful generic structure, i.e. Rolons, may have wide-ranging value.

Bill

[Ged Byrne]

Hi Paul,

The idea of active and passive Rolons relating to IPs and Processes is what I was thinking of.  

I like the idea of a common language that can be used to describe a range of approaches in an understandable way.

For example, to be able to describe Actors and FBP using a common framework that makes it clear what they have in common and where they differ.

We can say that Actors and FBP are similar, but that with Actors the processor travels to the data while in FBP the processor is conveyed to the processor through connections.  It's all to hand-wavey though and no two people can agree on the definition of what a processor is or what we really mean by data.

If we had such a framework we could start to put together log books like other engineers have where data can be gather regarding what approach is best applied given a certain context.

Rolons in particular intrigue me because I'm always looking for that next stage in the evolution of objects.  As you say in the book, FBP and Objects are both are convergent paths.  

Regards, 

Ged

[William la Forge]

Ged,

Part of what I find interesting about Rolons was that it provides a means of integrating knowledge and active elements, which is an inversion of the knowledge representation of the semantic web.

Also, Norm was always placing an emphasis on the ability to reinterpret past event in the light of current events--what he called retrodiction--and something which he said was a property of all living systems. Norm's approach to the development of Rolons was to analyze the behaviors and capabilities of living systems and build a theory capable of modeling them.

Bill 

[Ged Byrne]

Hi Bill,

This may be the main point of difference with FBP.   Does Norm seek to make this evolvability an automatic part of the system?

I believe that FBP seeks to create a socio-technical system where the evolvability is created through the human interaction.  The simplicity of the flow networks makes it easy for the systems to be adapted and extended based on input from a wide range of stakeholders.

This is made possible because the interactions between OPs and IPs is sensible for most observers, as opposed to the "magical" way systems tend to behave.  To fully appreciate FBP you have to view it in this wider social context.

Regards, 

Ged

On 11 May 2012 10:00, William la Forge <lafo...@gmail.com> wrote:

Ged,

[...]

[Brad Cox]

Exactly!! Its the same as the difference between building with mud and clay from the building site versus buying bricks at Lowes. Even though the former is utterly free and ubiquitous, essentially nobody builds with local mud any more. 

Its not mainly for technical reasons (assume for now sun-dried mud and baked bricks can be equally sound). Its for social reasons centering mainly around trust. Only the builder knows how good that mud is while Lowes bricks are backed by standards and testing labs.

That's roughly the difference between primitive and modern. Primitive == free and self-reliant. Modern is elaborately collaborative and generally NOT free.

[William la Forge]

I really only ever had the smallest understanding of Norm's unpublished theory, but he did say that many of his ideas were becoming mainstream, so his only innovation was their integration.

He likened Rolonics to a snowmobile, which contains not a single new idea except for the integration and application. On the flip side, a lot of his work was based on philosophical and mystical systems which were far from main stream. Had a PHD in graph theory too. Bright guy, but very very very deep.

I do know that had managed to encompass the idea of genetic algorithms into Rolonics, so yes. I believe he was working more towards something that could collaborate with users rather than enhance. But he also emphasized the unknown quality, where Rolonic-based systems (he has developed several products for fortune 50 companies) interact with users more naturally than other systems, but in ways that couldn't be easily qualified.

I never got involved with his products, but worked entirely on a wiki/mail-client/ontology-engine as a tool for his personal use. And have been struggling with same ever since.

[William la Forge]

It is the desire of my heart to be less independent and much more collaborative. I'd love to help with things that build on JActor and to get help evolving JActor.

Oh yes, I do have some news. I've got a preliminary number--400,000 durable transactions per second on my viao laptop (i5 with SSD). This is the rate that JFile's transaction logger can durably log transactions. (Code is in github and will be released in a few days.) My short-term goal is to build an in-memory database that can process durable transactions at roughly the same rate. And I'd love to be working with other developers on this. (I suspect that these numbers are pretty good, as most systems don't use forced (fsync) when performance is needed.) (Email me at lafo...@gmail.com if interested, please!)

[William la Forge]

I've been trying to recall what is so nice about using Rolons. First, I should qualify that they are really proto-rolons, Norm's true Rolons need to support things I haven't a clue about. :-)

I already mentioned that they are of a standard overall structure. I should have said that they are extensible in standardized ways as well. So an application can extend some Rolons in one way while other applications extend them in other ways. This makes sharing data between applications implicit in many cases.

The other point which I did not allude to is that Rolons have no size constraint. They might not even fit in RAM. So you can easily use a Rolon to build an index to many other Rolons.

Of course, I've also built Rolons over a versioning database. Handy for when multiple users are collaborating in a wiki. But there's this whole concept of 2-time developed in the insurance industry which can now be applied and it is nice for lots of things like viewing how project deadlines change over time.

Norm observed that there have been many universal programming systems that have failed in the past and that part of the reason for this was that they did not handle time very well. Time is a part of many different kinds of applications, but how time is used in different applications varies somewhat. Consider the use of time in a full-featured wiki, the use of time in an accounting system and the use of time in a project management system.

Bill

[Dan]

I have read some info about Rolons from the sites you have provided but I have not grasped those fundamental ideas about them. Besides that when I am hearing about XML I am getting scary. I have the feeling of a theory with fancy names and without content. What am I missing? Maybe everything.

Regards,
Dan

[William la Forge]

Now you know why I stopped talking about this stuff. As I said before, it is like listening for the sound of one hand clapping--literally!

Oh, and there's no XML. I just used the idea of a DOM as an analogy. Really just persistent trees made of a variety kinds of nodes.

My approach these days is bottom up. Do the pieces, finish them and explore their value. Like the latest release of JFile (which I forgot to actually release, and now the internet is too flaky to do the uploads) that provides a framework for processing up to half a million fully durable transactions a second.

Bill

[William la Forge]

Ho! Just managed to upload JID 1.0.2 and JFile 1.0.0 RC3. 

[Paul Morrison]

On 11/05/2012 9:21 PM, William la Forge wrote:

Norm observed that there have been many universal programming systems that have failed in the past and that part of the reason for this was that they did not handle time very well.

Yes, the two Pauls (Paul T. and Paul M.) were just talking about extending triples with a time dimension - not Warsaw is capital of Poland, but it was, and is currently, the capital of Poland from one point in time to another point in time.  When my grandfather left there, it was actually in Russia :-)

Another comment on time: Nate Edwards and his colleagues have talked about what one might call the "accountant's machine" - the real data is a log of transactions, none of which can ever disappear.  If you want to reverse a transaction, you have to add another offsetting one, probably at a different point of time.  A database then becomes just a snapshot of the data values at a particular moment in time.  And theoretically (and given sufficient computing resources), you can view the data as of any point in time, by running the log forward or backward.  Some of these concepts may be in Nate's ALTOPS work - see  http://groups.google.com/group/flow-based-programming/browse_thread/thread/9d4a0ead3fa378bf  , which I am sure he would be happy to talk about. 

I am also wondering if this is at all similar to the Rolon or Agilewiki work?

Regards,

Paul

[William la Forge]

In Rolonics, there are two times. Consider the problems of detecting fraud in insurance claims. There is the time the information about an event is entered (and/or given to an agent) and the time the event is reported to have occurred. These two times are used in analyzing the events related to a claim for potential fraud.

The second time can, for some applications, be a future time. Consider a project management system. There is a time when you enter (or change) the date of a deadline and the deadline date itself. If you look at how the deadline date changes over time of entry, you might see a deadline that is perpetually set to one week after the date of entry--a sure sign that a project is in trouble.

Also, some very popular small-business accounting systems allow you to enter the date a transaction occurred (the date on a receipt), without tracking/reporting the date of entry. But without tracking both dates, it is too easy to cook a set of books.

One of the big things in Rolonics is intention. An intention has a who and a what, as well as a completion date and/or  a start date, as well as the time the intention is entered/updated. My work has been classed as proto-rolonic, because I don't do anything with intentions. Which is fine, as I've had my hands full enough as it is. But intentional systems sound fascinating.

Bill