Friday, January 14, 2011

Ethical and Legal Aspects of Unmanned Systems. Interviews

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

Ethical and Legal Aspects of Unmanned Systems. Interviews



Gerhard Dabringer (ed.)
Ethical and Legal Aspects of Unmanned Systems. Interviews
Austrian Ministry of Defence and Sports
Vienna 2010
ISBN: 978-3-902761-04-0

To obtain a complimentary copy write to:

Institut für Religion und Frieden
Fasangartengasse 101, Objekt VII
1130 Vienna
Austria (Europe)

or

gerhard.dabringer@mildioz.at (if you do not receive an answer please write to gdabringer@yahoo.com)

For delivery to the U.S. or other overseas destinations, please allow USD 8 for postage and handling.

For delivery within Europe, please allow EUR 6 for postage and handling.

It is also available as a pdf in our download section:
http://www.bmlv.gv.at/wissen-forschung/publikationen/publikation.php?id=609

Contributors

John Canning, Gerhard Dabringer: Ethical Challenges of Unmanned Systems
Colin Allen: Morality and Artificial Intelligence
George Bekey: Robots and Ethic
Noel Sharkey: Moral and Legal Aspects of Military Robots
Armin Krishnan: Ethical and Legal Challenges
Peter W. Singer: The Future of War
Robert Sparrow: The Ethical Challenges of Military Robots
Peter Asaro: Military Robots and Just War Theory
Jürgen Altmann: Uninhabited Systems and Arms Control
Gianmarco Veruggio, Fiorella Operto: Ethical and societal guidelines for Robotics
Ronald C. Arkin: Governing Lethal Behaviour
John P. Sullins: Aspects of Telerobotic Systems
Roger F. Gay: A Developer’s Perspective

.

Wednesday, December 15, 2010

A General Application Engine

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

One of the difficulties in creating a good description of HLL is that most of the good words have already been used. Consider the following.

What is High Level Logic (HLL)?

“High Level Logic” (HLL) occupies a new position in relation to other software development tools and components. What is the highest level of general support that can be given to software development is the theoretical question that drives HLL development. Over the past 25 years, concrete and practical results have developed from this unconventional approach to envisioning the next generation of software tools.



HLL is a software framework for developing a very large number of applications, linking applications and components that have already been created, facilitating relationships between people and organizations, for interacting with people and their agents, and increasing automation of pretty much anything. In short, it does what modern applications should do; and makes an entire infrastructure easier to develop and maintain.

The opening paragraph and accompanying graphic were added to a document to clarify what HLL is; putting readers on the right track right from the start. But now suddenly, there's a contradiction. The paragraph following the graphic says that "HLL is a software framework." The graphic itself places frameworks two levels down from High Level Logic. Readers can be left wondering, which is it?

To me, this is more than just an editorial problem. It's part of a general problem in developing the language that describes computer systems and software components. Another example in HLL is the use of the term "experts." My use of the term is directly related to the definition found in English language dictionaries. I clarify by calling HLL experts, "HLL experts." For those familiar with AI, the term automatically causes one to wonder whether they're the same thing as rule-based expert system components.

I believe I can use the term framework to describe HLL. I believe it fits existing definitions and uses of the term software framework. But as the graphic shows, I think there's a need to make a distinction between HLL's position on the level-of-logic chart verses the many examples of frameworks that I'm currently familiar with. Knowing that any new terminology is one more thing to explain, I still think it's worth trying to come up with a new term.

The first thing I thought of was that HLL is an application engine. It clearly fits earlier uses of the term "engine" to describe software systems that drive applications by processing application components that have been expressed as data. (Rule-processing engine, for example.)

Ther term comes rather close to Google's App Engine and PeopleSoft's Application Engine. Google's App Engine is a platform for developing and hosting web applications in Google-managed data centers. PeopleSoft's Application engine is a batch processing system using blocks of PeopleCode and SQL.

Both the Google and the PeopleSoft "engines" are much more specialized than HLL, so to make the distinction, HLL can be called a general application engine.

What do you think?

.

Tuesday, December 14, 2010

Millions of tires travel billions of miles (1)

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

When I was young, before everything was made from synthetics, we heard stories; stories about undomesticated tires living in the woods near the highway. We had seen them ourselves resting in muddy sties and dangling like monkeys in trees.

According to legend, rubber is alive. As old cars roll down the road they deposit microscopic particles of rubber on the pavement. Each particle is a larva. At the moment of birth the tiny prototires instinctively migrate toward the shoulder of the road. They join others along the way forming thin processions that in the scale of the old west would form a wagon train a thousand miles long.

When they reach the shoulder they form small colonies. As more protos arrive they become larger clusters. When large enough, they become the clutter that motorists observe as they speed by. The last stage happens only on the night of a new moon, when the treads undergo a convulsive involution and emerge as mature tires.

The life of a wild tire is tough. Those that make it to the edge of the road and adulthood face further challenges to their survival. After midnight on the darkest nights, tire harvesters cruise the roadways and load their trucks.

There is an advantage to their isolation in the woods near the highway. It’s key to their survival. No humans live there. Most people don't go there except for the occasional moment or two of relief. That's why undomesticated tires go mostly unnoticed, why modern science hasn't written about them, and why great journalists don't comment on their social and economic plight. People notice them sometimes. But they don't really see them, if you know what I mean.

At first we took the stories for just what they seemed to be, just stories. It was entertaining to hear the theory of their birth as the parent tires of our own car rolled along the road. We thought little of it of course, like ghost stories and claptrap on UFO sightings. How strange to think that some people believe in alien visitations.

But we decided to test the theory of undomesticated tires. It was an advantage living in a small town. There were so many quite country roads not far from where we lived. Many were paved which is absolutely essential to serious tire colony hunters. When we spotted a likely spot, we could stop the car and investigate, chat for a while and enjoy the sun. That led to the first of what is now our traditional Sunday drive. Three of us, now four, scouted the highway looking for ripe clusters.

The most exciting event would take place with the new moon. We began exploring three weeks early hoping to find the best spot. John is a fisherman and lectured endlessly about the effects that temperature, instinct, and even rain might have.

We discussed the possibility of danger and then chuckled it away. "Have you ever heard of anyone being mauled by a freshly constituted clan of retreads?" I've tried to remember who said that first, but always come up thinking it was a joint effort, something that emerged from the loose clutter of jovial prattle.

After about two weeks of intensive searching and note taking, Mary declared a clear winner. Out on State Highway 14 a group of clusters had formed that reminded us of a grand community of fire ants. Surely, we thought, each hill would produce a bicycle tire. The site also had the advantage of interesting terrain. We thought about sitting on the car with sandwiches and maybe a little Lone Star beer. "A real night of it," we said.

We wanted all to go perfectly and so a week later we started the evening working down a checklist. Food - check. Beer - check. Ice - stop at the convenience store on the way. We then headed for the highway for a last check of the site before picking up our supplies. It was still early and we didn't expect anything to happen until after dark.

We headed toward State Highway 14 in the mood for a party. John and Mary began building the excitement, telling stories about what we might expect that night and exaggerating the character of our find. When we reached the highway, we met with a surprise beyond all earlier expectations. Still several miles from what had been our best site was a new colony, with black rolling hills and valleys that contained enough tread for a whole sixteen-wheeler.

Mary got all excited. She kept telling me to stop and turn around so we could inspect the mounds. She sounded frustrated with me as I continued driving, eyes fixed forward like I didn't hear her. I saw something about a hundred yards ahead. About half way Mary saw it too. Then John said, "Geeeezzowie!" There was another great mass of chips, shreds, curls and treads about twice the size of the last one.

A hundred feet ahead came a third dark rolling mass. This third colony tapered off to thin low trails meandering through isolated rubber villages, then shot up again into massive towers. Mounds of varying proportion began appearing on both sides of the road with trails between each forming a continuous chain of bustling cities.

We drove on, dazed. The mass on the right side of the road faded again continuing in a smooth thin trail, not ending until it climbed to a gargantuan metropolis where the anthills of our chosen site once stood. The new moon would appear that night. Like the shores of ancient China, Greece, and Egypt, the edge of the road had become the birthplace of a great civilization.

We were numb and silent as we rolled down the highway in the car. What this meant and how it had come to be in such a short period of time was boggling my imagination. I needed to collect my thoughts.

John broke the silence. "It's midsummer's eve."

In Texas, people have long since forgotten the ancient celebrations of the seasons, having found no reason to celebrate midsummer especially. It's warm most of the year, when it's not hot. Better to rouse a sleepy air-conditioned bar or relax in the shade with an ice-cold glass of tea than to embrace the weather with any ritual.

"Frogs …" John choked. Mary and I looked for frogs on the highway but saw none. We looked at John and then at each other. He knew about midsummer's eve because of his knowledge of fishing and frogs. That didn't matter, or so we thought.

We looked back at John again. He was leaning forward with his hands over his face. Mary and I began rethinking our plan. We decided to park the car and hide in the woods behind one of the communities, somewhere we wouldn’t be detected. We decided to stick to the old plan when it came to sandwiches and beer, except for the ice. We’d have to start out with cold ones after dark.

A spot on the hillside beneath the great metropolis seemed right for our purposes. We could sneak in over the thin trail of rubber huts nearby and drop quickly into cover. So that was the plan. John never said another word, except once. He was staring down at his shoes, red-faced, shaking his head and pulling his hair. “Frogs,” he said. And then again, “Frogs.”





As we saw the last orange glow of sunset we assembled the sandwiches and beer and made our way across, hauling John along by his hand.

At home, Mary's mother looked out of the kitchen window and began to wonder. She had a special sense when it came to her children and she sensed something now. She knew it was best not to worry. She continued to gaze through the window into the back yard where Mary used to play and gazed deeper into her sixth sense. Something was going to happen.

Mary and I scouted the area stealthily, communicating in whispers and hand signals. The plateau held a small group of trees to rest our backs against as we sat and waited through the night. There were bushes hiding us but we could see around them when we wanted to. Mary pointed up the hill and snickered, “The Great Mounds of Roador.” We lost control and chuckled a bit too loudly, then both sounded “sshhh!” and broke up chuckling again. It helped ease the tension.

The location secured, base camp established, we turned our attention to the sandwiches and Lone Star beer. John was sitting quietly in a clump of bushes, staring intently in the wrong direction, down the gentlest part of the slope toward a large nearby pond.

Mary and I took our duties very seriously at first, somehow imagining that we knew what they were. We tested our skills as sentinels, sneaking a peak and darting back to cover again. The moon was bright and the sky clear. We began mapping the features of the metropolis for later comparison, only twice pointing out shadows and correcting ourselves.

Late into the second beer, I sat back and relaxed a bit and shook my head while pealing the label from the bottle. “The Great Mounds of Roador,” I mused. Mary smiled back, encouraging the light chatter.

I pitched my voice higher and became a little sing-songy. “Road decor, in the great tradition of Marshall McLuhan,” I said.

The snickers were quieter now. Mary responded faking a low voice. “Road memorabilia.”

We were on a roll and I fired back with my best imitation of Johnny Carson. “Interstate ennui.”

A question shot across Mary’s face. I shrugged my shoulders. She downed another big gulp of beer.

Sounding more philosophical she asked, “if there's rubber on the road, did the blown tire make a sound?”

By then I felt forced to go on. “Is a tire only the afterburn of the wheel?”

With that, we each took another Lone Star, tipped them in quick salute, and drank. Each swallow took us deeper into the philosophical ramifications of rubber. Around our fourth bottle (each), we were convinced that the situation was of enormous importance to the future of humanity. It was on that account that we began to formulate a daring plan.

..

All the characters in this story are fictional, and any resemblance to actual persons living or dead is purely coincidental.

All rights reserved.
Copyright © 2000-2010 Roger F. Gay.

No part of this story may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the author.

HLL on Linux

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

The day has come. I've been developing in Windows for a long time; never seeming to get around to installing Linux on something for testing. After a disk drive on a laptop pooped out, the difficulties of getting Windows back pushed me over the edge. Ubuntu was simple to install, but since I haven't been on a Unix system for many (many, many) years, and this is my first experience with Linux, some of the rest ... well - let's just say an experienced Linux guru would have been posting this a couple of weeks ago. (Not like I dedicated 24/7 to this task though.)

Ubuntu comes with some kind of Open Java, so I eventually figured out how to uninstall that and installed Sun Java. Then I installed Apache Tomcat just in case. I haven't tried to run that yet, so I haven't tested the optional HLL browser built as part of the robot demo.

Quite frankly, I don't even know how to create a script file in Linux yet, so I typed in the java command to run HLL by hand rather than converting my Windows batch files. But sure enough, write once run anywhere - the "Hello World!" demo works. No recompile necessary.

Saturday, December 11, 2010

Java Needs an Opt-Out of Static Typing

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

I've, step-by-step, been explaining the history and character of the high level logic problem and the solution being developed in the HLL Open-Source Project. More than once, I've mentioned the enormous advantages of modern computer languages over what was available twenty-five years ago when the first few of my brain-cells became stimulated by the question. For more than one reason, I've selected Java for the implementation language. (One that I'll note is that it's currently the most popular application language on the planet, matching the intent that HLL should be a production tool, rather than an interesting curiosity.)

One great issue remains, however. Java is a statically-typed language. Why is that a problem, you might ask if you haven't yet seen it as a problem yourself? Let me take an example. I have mentioned JBoss Rules (also known as Drools) quite often in my articles. In The Ghosts in My Machine: Chapter 2 I mentioned how it overcame a critical problem in the ancient art of rule-processing.
Popular rule-based expert system tools had been built as stand-alone products to support only rule-processing, and could not be integrated with other programs and were not extensible with other programs. The JBoss rule processing system mentioned in chapter 1 deals with this problem directly. The rule-processing software is built in Java, carrying with it the characteristics of the underlying language. A rule-process can be initiated from another program and program objects can be referenced directly in rules. This allows programmers much greater flexibility to fashion their own hard-coded relationships between rules and other components in each application.
In HLL, I am about to create a similar openness in the configuration system, and that will be carried over into a simple rule-processing and planning system directly supported by the HLL core (with the option to use a more sophisticated systems such as JBoss Rules). Application developers will be able to specify their own components in XML files that the HLL processor will handle generically.

In the prototype, developers could add their own components to the core – which is very much like saying they can add whatever they want by changing the core source code. (Well, du-uh!) Because I want to maintain the concept of the core, a next sort of “bottom-uppish” evolutionary step is to predefine another package specifically for application components (that may in turn initiate other systems that HLL doesn't know about). The HLL core processing components that deal with configurable application components will have all members of the predefined “application package” imported by using a wild card (import nu.isr.hll.light.application.*;). Application developers will be able to put initiator components in the application package, and the HLL core will process them in whatever way is described in (XML) configuration files.

One HLL unit can also contact another HLL unit with a request to have one of its application components executed, with results returned. But I dream other dreams. I would like to build dynamic HLL applications that can process components that were not defined at compile-time. I'd even like to be able to fetch objects from somewhere out in the WWW that a particular HLL unit has never heard of and run them locally. What I'd like is a LoadUndefinedClass class with methods for calling methods and accessing public fields.

And really, I can almost do this with generics. I can almost build the LoadUndefinedClass class using reflection. Almost isn't good enough, of course. No matter what trick I play on the compiler, the run-time engine is going to throw an error if there's no predefined class for it to refer to.

So, what's stopping us from getting a LoadUndefinedClass class? Purity of the language? Fear that Java programmers might write programs that don't work? Come-on!!!

UPDATE (Sept. 6, 2011) InvokeDynamic class : New JDK 7 Feature: Support for Dynamically Typed Languages in the Java Virtual Machine
.

Saturday, November 13, 2010

Regarding Human Intelligence and Decision Strategy

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

When Will We Have Artificial Intelligence?

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

When are we going to have AI, one survey asks? It's a question relevant to HLL because so much of the thought behind the HLL design comes from the history of AI research and current technology that has come from AI research. The answer to the question when, with reference to HLL, is now. (Or at least as soon as version 1.0 is ready.) And that's no reason to get worried. As the description of HLL claims, you don't even need a high-powered computer science background to build applications with it – just some (OK, but at least reasonably good would be nice) programming knowledge.

The AI question is actually a bit tricky. It really depends on what you mean by AI. Way back in the cave computer days when I was first introduced to the subject, artificial intelligence research was defined as trying to get computers to do things that humans currently do better. Applying that definition, it seems as though the answer may be never. As soon as computers can do something at least as well or better than humans, it's no longer the subject of AI research. Object oriented programming is an example of something that came from AI research. Now a mainstream programming paradigm, many people don't associate it with AI at all.

The variety of ways of thinking about AI is also why some researchers predict AI won't exist far into the future while others (like me) are much more optimistic. People who answer the question may have something very specific in mind and think it will be a long time before it will become reality. You can also think about all the things computers do now – such as mathematical calculation – and make a case that AI already exists (something humans and computers both do, and computers do well). The great variation in predictions on when AI will come, has to do with both the particular sets of things that guessers think need to be done before “AI exists” and how optimistic or pessimistic they are about doing them; while basic research always looks ahead.

You've probably heard that human intelligence is linked to the fact that we have opposable thumbs and other peculiar physical characteristics like standing upright and walking erect. Researchers recognize that in living creatures, intelligence and the characteristics of their physical bodies are linked, which makes robotics fertile ground for AI. (related article) Not all researchers focus exclusively on human intelligence and capabilities however. Some of the most interesting advances have come from looking for ways to mimic the behavior of other creatures, from insects and snakes to mules. The intelligence of a lower species is still intelligence, and some of the developments that come from mimicking their behavior can be applied in layers when mimicking behavior in higher ones.

Where does HLL actually fit in? Twenty-five years ago, when I was first thinking about the “high level logic” problem, I thought of it as a subject for advanced research. Since then, computer languages have advanced considerably and in ways directly matching the requirements of HLL. Strong networking support is a must, which has come from focus on Internet applications. Relatively recent additions to Java (which I've used to build HLL), such as strong support for generics and reflection have transformed some of the challenging bits into stuff that's just pretty cool.(Once again, application developers are not required to have expertise in these techniques – although it's quite alright if they do.)

To some extent, even the concept has been encroached upon (so to speak). The short descriptions of HLL have called it an “agent system” and I worry at times that it will be perceived as nothing more than an alternative to existing agent systems (which I won't mind so much if it becomes a popular one). The overall HLL concept is the thing that remains new, and while fitting into the current modern software development world well, I still think it has potential as a tool in advanced AI research and application development.

HLL development has been proceeding as an ordinary software development project. With use of modern software technology and twenty-five years of thought behind it, not much experimentation is now required; less than the ordinary amount for development of a complex software system, because even details and how it all fits together have previously been thought about. And all that is why it (version 1.0) will be a powerful, light-weight system that is easy to use.

So, is it AI? When people are using it regularly to build applications, I certainly hope it's thought of as AI just as much as rule-processing or object-oriented programming and all the other things that have come from thoughts on developing AI; and yet, fully accepted and integrated into mainstream applications development. Why not integrate HLL support directly into programming languages?

For most people, thoughts on what AI is continuously focus on the future. With twenty-five years of history, I think I've earned the right to use a tired old cliche to end this note with a response. As far as HLL is concerned, the future is now. (Finally!)

Another view: How Long Till Human-Level AI? What Do the Experts Say?
(AGI = Artificial General Intelligence): “I believe the development of AGIs to be more of a tool and evolutionary problem than simply a funding problem. AGIs will be built upon tools that have been developed from previous tools.”



.

Wednesday, November 10, 2010

HLL Factory

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

It occurs to me that HLL application units should be easy to integrate with other types of application components. The current design allows any sort of application component to be integrated into the HLL logic - since HLL was conceived as the "high level" logic for applications. Interaction between HLL units (an agent approach) is fundamental to the design.

But, some application builders may want to incorporate HLL unit technology within other types of programs. I haven't thought of a reference or example application yet, but it seems kind of obvious conceptually. There may be an HLL infrastructure operating already. An application designed in some other way may want to interact with it, with either fixed or variable specifications for its exact purpose.

In such cases, an application may want to make use of an HLL Factory to construct an HLL unit on the fly that will interact with other HLL units just as one of them. The fact that HLL pushes the high level application logic specification into data would make it easy to create or modify the specification on the fly.

Creating a good HLL Factory set-up would take some thought in design, but is quite doable. So much so that I expect, as the concept of an HLL Factory matures (along with completing more of the code to version 1.0), it should surely be done.

I have added HLL Factory to the issues list, but not as a high priority. Since HLL is not version 1.0 yet (but getting closer every day - and I'll remind everyone that is it already possible to build applications) - and there is no existing HLL infrastructure anywhere out there (although there are agent systems running), I sense no great demand right now for dynamics to interact with an existing HLL infrastructure. The day will come however ...

Sunday, November 7, 2010

The Ghosts in My Machine, Chapter 3

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

Chapter 1
Chapter 2

Prepare yourself for a surprise ending. Do that now to avoid confusion later.

Around 1990, I met with an industrial engineering professor who had been working for years with artificial intelligence technology. We had a long chat about the possibility of completely automated factories. This was still a decade before frequent online purchasing and customer management systems. But it seemed reasonable to contemplate a future in which everything from initial customer contact, sales, accounting, instructions to the factory floor, robotic manufacturing on demand, packaging, right out to the shipping dock would be fully automated.

Even if you've never considered designing such a system and are unfamiliar with any such work in that direction, it isn't long before the thought occurs that such a system should be broken up into departments and operational segments. Each operation has its own specialized “knowledge” and processing to contend with, and it seems likely that interfaces between operational segments might need only handle common data exchanges. Jumping ahead, one might consider that an agent system could provide loose coupling between operational components as well as the possibility of moving pieces around from time to time for special types of interdepartmental operations.

It isn't a big jump to consider that breaking the application into “departments” is at least in part, an exercise in modeling the framework of the human organization that complete factory automation would replace. The fact that this model already exists, that it's completely common, may be the most important reason that the idea of breaking the software design up this way is so obvious. Compartmentalization is not a concept invented by computer scientists. Humans do it all the time, and have been doing it for ages. If we're going to think more about obvious common ideas, then this idea easily qualifies on that ground.

The concept of an “object” was also not invented by computer scientists. (I merely need to open this idea so that I can be flexible about its use without confusing anyone – i.e. a fair warning against thinking “simply” about common current day object oriented programming structures and techniques.) Objects exist in the world around us and we can ourselves be described as objects and operate as such. They have characteristics and some have capabilities. They interact in various ways and react in various ways to interaction. Complex (compound) objects can be composed of simpler objects; the whole sometimes being equal to more than the simple sum of its parts. The concept of an object or “entity” (in certain modeling models) is fundamental and useful in describing pretty much everything – solid ground for high level logic.

Dwelling on what at this point may seem quite obvious; we're – very generally speaking – looking to design a set of organized objects. One way or another the individuals and / or the organization will be structured to carry out tasks and solve problems, answer questions and whatever. The important distinction here is that the intent is to build a general processing engine; not a specific application that could be described exactly the same way – as a set of organized objects. The expected practical effect, if successful, is that some portion of “common” logic in a wide range of applications can be moved into the general processing engine, where it does not need to be repeatedly rebuilt in the application phase.

Another important distinction is that the High Level Logic Project attempts to do this by searching for “high level logic” rather than by “bottom-up” development. This is why I've chosen such a long-winded approach to introducing HLL. Ideas that are common and fundamental are useful and enduring. They don't need to be derived - "bottom-up" - from the most recent set of application programming frustrations.

So let's take the next step in thinking about departments in human organizations. There are various kinds of organizations, but I didn't mind leaning on my familiarity with the typical American corporate structure, and particularly with project oriented groups. Projects begin by defining a task or problem and end with a specified result. There is at least a rough analogy between this process and the general problem solver outlined in chapter 2. Project organizations are made up of individual people with specialized roles and responsibilities that form sometimes simple and sometimes complex task hierarchies.

Certainly our task cannot be to describe the individual characteristics and operations of all existing human organizations, or even of one large organization like IBM. Organizations change, and a detailed description of any specific organization is not a general model. A general high level logic engine needs entities that can be characterized by application developers or another process. The system for describing organizations needs to be easily extended by adding, defining, and organizing entities. The relationship between entities needs to be “loosely coupled” so that they may move around, help others by use of their special knowledge and capabilities, and form sub-groups to perform tasks as needed.

There is a difference between general and generic. The description above remains pretty generic. Certainly, organizations as “organized objects” seems so. It is possible to add more specifics to a general model (applying to all or most members of a category or group), or one postulated as being general (not specialized or limited to one class of things) without fear of limiting an application developer's creativity and adaptations to meet specific requirements. Allowing developers (and other processes) to customize, add, delete, define, redefine, and organize – i.e. to completely control the specific definition of the generic engine's application does that. (It's something like bringing entity-relationship diagrams to life.)

But still, it plagued me that there is apparently at least a rough analogy between the workings of a project organization and the general problem solver outlined in chapter 2. What minimal organization could assure complex task completion and be highly relevant to a wide range of software applications?

I had spent years working in project groups, and it was that experience that I most thought about when making the analogy. Generalizing a bit, the organization started at the top with an executive (like a VP of Engineering), who reigned over one or more (project) managers, who organized and managed the activities of groups of experts (in most of my personal experience – engineers). In the human world, such a simple three-layered organization has been responsible for carrying out a very large range of very simple to extremely complex tasks.

It was time to describe the characteristics and capabilities needed for a basic three-layer organization model, one that made sense generally, and would be highly relevant to a wide range of software applications. That part turned out to be not particularly difficult, and led to detailed design requirements and specifications (chapter 4, some of which are already hinted at in this chapter).

Minimal description of the three-layer HLL general organization model:
Executive(s): Interacts with external and internal “interests” to formulate, offer, accept, or reject proposals or demands. Decides whether or not to make commitments. Is concerned about the general allocation of resources within an area of responsibility. Assigns complex tasks to managers.

Manager(s): Plan an implement tasks that have been assigned to them, using available resources.

Expert(s): Carry out work details for which specialized knowledge and skills are needed, often in cooperation with other members of a group.
Very clean model so far, perfectly obvious in many respects. On the good side, it could easily be taken as a generalization of many processes including many, many software applications. Then I felt a great discomfort with the human organizational analogy. I and a great many others often feel discomfort with being a cog in the wheel of an organization. It's not quite natural. Something is wrong. (Here comes the surprise ending.)

Don't we all, individually, commonly carry out tasks requiring all three levels described above in our daily lives? What's the difference between a large distributed organization and an individual (in the context of this discussion) other than that large distributed organizations can get a lot more done in a specific amount of time? There isn't necessarily a difference between the structure and function of a multi-person organization (model) and an individual.

A friend of mine who happens to be a cook recently asked me to explain that to him. A cook, interacts with the outside world (outside the kitchen); a good example being the communication of an order from a customer via a waiter (an agent). The cook may accept or reject the order. (If for example, the order is not complete or the kitchen has run out of an ingredient required to make a dish.) If the order is accepted, he commits to the task, then assembles resources (ingredients, cooking implements) according to a plan (complete dish specification and recipes). He then prepares the food and the dish, using specialized knowledge and skills.

The fundamental high level logic had not collapsed, but it became apparent that application developers should be provided with the greatest flexibility in interpreting, mixing and applying its pieces. Large organizations like IBM are human creations, sometimes necessarily physically distributed, that can accomplish more in a particular amount of time. Otherwise (in the context of this discussion) nothing more than a reflection of ourselves and the way we – necessarily – accomplish tasks that require a higher level of intelligence.

From the High Level Logic (HLL) Open Source Project blog.

Thursday, November 4, 2010

XML Configuration Processing – Progress Report

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)

It's like XML, but you can store source code in it.

The importance of issue #1. Configuration Files and Processing should not be underestimated. The configuration system is used to attach application components to the generic HLL processing system. It makes sense to create a powerful configuration system that is easy for application developers to use and quite flexible so that it does not impede creative development. And when the project begins building tools to further simplify the development process, they will (in part) simplify the construction of configuration files that, in effect, define HLL applications. A powerful configuration processing system will facilitate powerful but easy to use tools. (For programmers, the process is already easy even without the tools.)

In addition, what is becoming a sophisticated configuration processing system will be extended to process plans (management layer) and then further extended to build a simple rule-processing system. (Sophisticated rule-processing can be handled by existing sophisticated rule-processing systems.) All of these features require processing XML files in sophisticated ways. (Including things like handling class and method specifications generically, building things on the fly with reflection techniques, and constructing and modifying the XML files themselves on the fly.)

My progress on developing the configuration system has been interrupted by other demands; just the sort of thing that one must expect in this kind of project. I was, for example, invited to present the HLL project to a group of about 150 IT professionals in Stockholm, which I was quite happy to do. And if you've been following this blog, you know I've spent some time drafting commentary on HLL in a way that I hope provides a meaningful introduction. (If you have been following, please note that I expect chapters in The Ghosts in My Machine to become less historical / philosophical and more concrete and technical, eventually explaining the design and how to build applications.)

The prototype already had a working configuration system. It would not have been a working prototype without one. But it was much less flexible than it should be in version 1.0. In order to get the prototype up and running quickly, I had done things like hard-coding configuration file names and wrote custom handlers for each file. It was good enough for proof-of-concept, but not what I'd call “real code.”

Back to work, progress has been good.

Configuration files and handlers are now specified in a master configuration file which is read and processed. It will also be quite simple to add an option to specify the master file as a command line argument. (So simple, that I may do that before committing the code.)

The HLL predefined configuration files are optionally checked against schemas. This option will be available for configuration files created by application developers as well.

I've decided to stop working on configuration for the moment. It should not take too long to deal with issue #2. FIPA Compliance , and I hope to include this, along with the current configuration file handling improvements in a new source code commit by the end of the week (i.e. tomorrow). Then I think it would be an extremely good idea to update the simple demonstration binary download and tutorial on application development.

It seems to me that moving on directly to work on plan processing before returning to configuration would be a good idea. It is intended that plan processing should be built on the processing capabilities of the configuration system. Work on planning first, allows me to simply paint on a fresh pallet with modified code from the configuration system to get the result that I want – assuring that it works for planning. Then I can return to configuration and simply apply the relevant new bits for the final upgrade.