Project Athena is the public launch project for Architected Futures.The project is currently in its formation stage. A project charter is in development and targeted for completion toward the end of 1st quarter 2017.
EATS exists as a functional system, a series of compatibly architected fragments (web and desktop), and an Eclipse JavaFx prototype in progress, morphing into v4.6.1. The documentation level is what you see here, all around, and a whole bunch more notes on my personal computers, and books and binders in my office, etc.
Where I go next, and how I approach it, will be a function of the level and type of response I receive from initial responders to my requests for review. First quarter 2017 is for figuring out the outlines of the next generation of development.
I have a generalized MGP in my head, and a general direction as part of my vision. That's written all over this document and "between the lines" in the material here on the website. That's the plan toward "the vision," which is a moving target that will never be reached. It follows the MGP outline shown below.
Mine for Wisdom & Efficiency
|Infrastructure Systems||Initial Collaboration System||"Real World"||Annie in "Virtual World"|
|Content||Operational Metamodels||Application Suites||Fully comprehensive knowledgebase|
|Community||Early Supporters||Federated User Communities||Fully engaged citizenry|
The current intent is moving EATS toward Annie and Virtual World. To get there, we need a Real World, and to get there, the first step an integrated collaboration system. And try to build out the other components in the process. I'd also like to set the groundwork for implementing some simulation functions which are a Gen II capability set.
Priority 1, from a technical view, for me, is to clean up the current "tool problem" in managing both "shared" and AIR content.
Vision Project Framing
These are notes for the "project document" for Project Athena.
Link to SOWA Ontology Brain.
The name is derived from A, first significant project, "Athena" for the Greeks and "Athena" as the god that sprang fully formed from the head of Zeus. As long as Zeus also took 11 years to work on it in his head before he birth her. Anyway, it has some classical appeal.
This document needs to have an official cover, etc. generated. It then becomes the directory backbone for project materials. Main documents in the system, including views of material originating here, will continue to evolve in the main library. This is a "project" file, with this node as its primary index. For examples, see some of the EATS documents, like the Design Doc. Those same documents, plus various Six Sigma documents, etc. are the expected contents of this file. If this were in the EATS Java side, I would work up some templates and a class hierarchy and make quick work of most of this. However, I less familiar with Drupal and I have limited bandwidth for this. Plus Drupal, which I still think it a good choice, has issues in terms of productivity. For now, at the beginning of Athena, the strategy is to try to structure as much as possible with an intent on developing standards for future use and projects, but sacrificing to expediency to get comprehensive useful specifications and content into user and developer hands. We structure the meta data structure as though it were final. We code the metadata into EATS as controlling metadata. We code the meta data into Drupal (e.g., Taxonomies and manual monitor correlation, maybe with some audit assistance) We code content into Drupal as best we can, trying to "source" from the AIR repository. Otherwise we build up Drupal nodes as EATS (primarily "documentation" elements). We work on a manner to read, parse and convert the Drupal nodes, and other "content" into AIR Elements by parsing the node content. (A modern version of what we did with the WISDM diskette data.) Project Athena needs to first create a community space where uses can educate themselves and become coversant on what we are doing, and how. Focus for 1st phase MGP activities needs to focus on user empowerment. Bring in additional Drupal modules as needed, but don't overload. Need to build up users and knowledge. The technology needs to support that which the first wave of adopters comes on board. EATS Java is secondary at this point. From a coordinated point of control basis, we are trying to provide 2 levels of coordinated management at this point. Management based on a "Architected Futures" MGP and MBB style effort, focused on starting Vision World. The planetary needs assesment defined the big context. Architectewd Futures / EATS facilities is "the system" of concern until we get out of Triage and can do some validations. Component threads and utilities, focused on an Alternatives Evaluation facility, defines what appears and relative important at the component level. We aren't focused on AI here, althouigh some prototype tools may appear. We need to build out the 4.6.1 architecture to be able to support agent based models, but models are not primary. We can benefit from a few good Pugh, Kempnor-Tregoe, etc. type tools. QFD would be a real beneficial tool. Some of this is to figure out general tool clusters in the technical architecture. Triage Solution Alternatives (Project Alpha) - Intergrate a version of Compendium in its native form as a facility of the ArchitectedFutures.net platform. Read access to the world (except those area and IP addresses that have been identified and listed as sources of illicit behavior as determined here. - - Compendium provides a facility, already field tested, by noted parties, for use as an argumention platform. There are quality improvments that could be made, but it is far in excess of (my) expectations in terms of making a "state of the art" statement for what it does and how it does it. --- JVS Note: (Patterns relates to tickler and enhancements to developer UX) It is very difficult with current tools to migrate and place content. The need for some UX better behavior gets increased as a fuction of the content volume of the knowledgebase. This is one reason for "avoiding" documentation. Which is becoming the exact opposite of progress, and is inversely affecting, or going to affect, communication on the part of a collective of people. The need for better "documentation" facilities makes a need for something that works, like Compendium start to become a "Triage Requirement" for communications. This makes sense even if the only two people working on this might be me and Thor. Doing that shoud be Triage for Project Thor. Compendium can be installed as a Java Web application, I think.
A vanilla install, I would hope, could be installed on a hosting service, and become an "extension" to af.net as a sub-domain, or whatever. We can do some name mapping to achieve that.
If we go that route, we get what OU developed, and then blend it into, or onto, EATS (There's also another version of the code to consider)
-- Initial implementation should be by means of integration behind the existing Drupal front-end that defines the current web interface (i.e., this site). Compendium can, or should be able to, operate on any arbitry web server. One issue will be to ensure that the interface quality of the existing Compendium UI is not degraded. -- To "do AF" we then need to work the content management side of Compendium. It can work "as is" as a "verticle" without being fully integrated. It becomes a "presentation management" client. But it needs to work with "architected content" in some form of architected manner. GUIDs, Element Types, etc. -- Drupal should be able to have some PHP "views" created to interact with EATS.
<See "Project Thor" 8x5 diagram, yellow tablets> In addition to Compendium and Drupal changes, the EATS desktop needs to move forward. The desktop architecture is the Core to the Thor->Athena->EATS MGP generational flow. The Patterns discussed in the referenced Drupal node are all EATS metadata coding that need to happen. I neeed to get rid of the inefficiences of dealing with the other editors. The EATS semantic editior is a very base level need. And it need a reasonable, integrated, visual editor for modles. Plus, we need to build some validation, verification type stuff for the models as we begin to populate them. All of that is EATS code. And we need a place to run it. Although it could colocate with COmpendium on a Java Hosting environment for shared use. Security policy will need development. Compendium can be installed as a Java Web application, I think. A vanilla install, I would hope, could be installed on a hosting service, and become an "extension" to af.net as a sub-domain, or whatever. We can do some name mapping to achieve that. If we go that route, we get what OU developed, and then blend it into, or onto, EATS (There's also another version of the code to consider)