My first blog post is about software for collaborating on complex problems by visualizing the semantic network of a "global brain" -- a graph of everyone's ideas and reasoning involved in the discussion.
a Social Network for Ideas
36 plus ones
Shared publicly•View activity
View 108 previous comments
- My link above is bad, but it gets you close. Chose "about" after you get the page not found error. (Couldn't see how to edit the link.)Dec 6, 2016
- Hi http://architectedfutures.net/content/about . (I only read the initial summary for now.) It would be easier to understand if there were some concrete examples of how you envision your system being used. (Maybe you have these later, but I already found myself needing these to understand the summary.) If you write a new summary, feel free to post a new link here., thanks for your comment. It sounds like your thoughts are indeed related. I found your writeup at
> Distributed, federated systems, I feel, are the answer ....
I completely agree. Make sure you also notice my followup blog/G+ post "Extensible Meaning in a Shared Cloud", which goes into some detail about this and many other aspects of implementation.
You (and I) are definitely not alone -- one of the main benefits of making my post was learning about several related projects (some already working) mentioned in the other comments here. See also my G+ community "collaborative design software" for some of these.Dec 6, 2016
- , This is a very complex subject, and I will be working in the (near?) future to clarify my thoughts for public consumption.
I see two different reasons for and approaches to what you are proposing:
- one is concept or project oriented. This is where I see most of what has been or is being developed. In this space, I see something along the lines of an IBIS derived approached (argument mapping) to be the most reasonable. Simply drawing network maps of relationships is insufficient to make the arguments to explain what is happening between the related concepts. The maps are sometimes useful, but nowhere near sufficient to actually explain things. But, it is a useful component.
- my approach is not project oriented. It is rather oriented as documenting and explaining systems, how and why they work, and the roles they play in larger systems of which they are a part. From the perspective of three stakeholders, one system, the system under examination, will detail out as three different systems, with some number of parts in common between the three.
Stakeholder 1 does not see or appreciate stakeholder 3's view, and 3 does not see 1's view, and neither of them fully understand's 2's view. These are wicked problems when you see coal mining as your livelihood and I see it as a pollutant threatening my grandchildren's health.
But that's only the start of the story. Even if you buy my concerns, there are still issues about what do we do about it and how do we get there. I have seen project after project fail because even though there was an excellent idea of what was to be achieved as a goal, there was to clear path defined for achievement that took transition impacts and effects into account to achieve that goal. This relates to a phrase I liked and used often during my paid employment phase of systems engineering: "It's perfectly okay to build dream castles in the sky, but don't phone Bekins to have you furniture moved or you'll be in for a rude awakening." The goal needs to be achievable, and the whole transition path of "here-to-there" needs to be mapped and achievable too. That's also part of what a true problem solving tool needs to support.
My approach is to map what is, from all of it's various angles and perspectives. Then you map what's desired, as another "whole system" design. Then you map the various feasible paths to move from A to B, and the pros and cons of using the different approaches
When ALL of the stakeholders agree using whatever reasonable political formula defines "all," you start to have a viable program.
Next, you have to recognize two things (at least):
- there are a multitude of other projects and programs that will walk the same path and impact a lot of the same elements on other projects that you are impacting on this project. They also need to be reconciled and managed to achieve their goals, with overlapping and new stakeholders, at the same time. (More mapping, creating the tools for understanding between more groups.)
- AND, almost none of the projects were perfectly designed to begin with, all will probably suffer multiple changes to direction and goals while the projects proceed, and all will have to adjust (impacting the others) while the work goes on.
This is what good managers do, all day, every day.
The project approach is what most efforts focus on, and that is a darn difficult space. Unfortunately, the sustainable, dynamic system management problem is the one that needs to be solved to get us out of the mess we are in.
What I see is a network of systems, that are designed to be able to work independently and in concert with other as federated entities. My personal planning system for my home or business should be able to link with, take input from, and supply input to a variety of other systems that I am a stakeholder in. My work, my community, my local government and school systems, my regional transportation planning systems, etc. And those systems should be able to interchange ideas, plans, issues, problems, etc, and they should be able to percolate up in a federated fashion and receive inputs and constrains from larger systems of larger scope that serve as environment.
When I as a voter am asked to record my ballot, I should be able to see and trace the logic of the whys and wherefores of the parts of the program that are impacting me, and understand why those choices had to be made. And when the "big project" starts trampling on my toes unnecessarily, that planner should be able to see my pain and know why they need to adjust their plan.
Given that, we can start, as a society unraveling and understanding the world we live in, and how our lives relate to others around us, and our children and grandchildren. We can identity what we can change, and what it's impacts will be, and what we need to let rest. We can identify and plan what we want to achieve, what we need to do to ensure survival, and how to get there in a manner that respects the other folks we need to share the planet with.Dec 7, 2016
- More specific use cases to follow, at some point.Dec 7, 2016
- Re comparing my effort to this effort, or Compendium, I see them as related but orthogonal. I view this as one of a series of "verticals" and my effort a "horizontal." On my "about" page it mentions "subject domains" ... this is what I would call a vertical subject domain.
My effort is aimed at dealing with multiple intersecting subject domains in an integrated, cohesive fashion. It's more of a an operating platform for a virtual concept management system than a specific application. The application would exist and run as "verticals" within the horizontal framework.
Specifics to follow.
In terms of mechanics, I have a blog post architectedfutures.net - EATS Infrastructure Prototype Code Published | Architected Futures™ that tries to provide a quick overview of an earlier version of my code, the Javadoc for which can be accessed from the post. It is 4 years old at this point but may be useful in terms of a reference to our future discussions and comments I make on other posts.
For what it's worth, I find this a very difficult system to work with as a discussion facility, but more on that on another comment.Dec 7, 2016
- From your long comment above (Dec 6th), it's clear we have very related goals. But from your last comment (the just prior one), you see your proposed system as "horizontal" and mine as "vertical". If I understand the metaphor you mean, I see mine as "horizontal", and I don't yet know enough about yours to say (but from your stated concerns I'd also say "horizontal"). But maybe you better define your metaphor, I'm not sure I guess it right.
I will say that I am not claiming to have solutions to most of the specific problems you raise; rather I'm trying to say "the general form of the solutions would be [a certain one I've outlined], and the general structure of a good system for handling them would be [what I outlined, or something equivalent]". But "system" there doesn't imply "single product" or even "single network". Rather, it's a set of integrated but flexible standards -- or maybe just principles -- for shared data and for federating separate systems and networks.
A loose analogy would be to someone proposing the general nature (but not yet the specifics) of the web, HTTP, and that a number of data/document formats such as HTML should exist. That proposal (the real one for the web, not mine) should, and has, led to many independently written pieces of software and independently run subnetworks. And (at the indicated stage) it is incomplete, more of a guideline than a spec. (That was even true after the first-version specs for HTTP and HTML, but my proposal is at a much earlier stage, more like having written just the intro and design principles sections of documents proposing those standards.)Dec 11, 2016
Add a comment...