This idea describes a portion of ThePublicWeb dedicated to projects:
The projects could be:
The space will plausibly self-organize itself into a network, which we call, “the ProjectSpaceNetwork.”
The ProjectSpace network is a self-organizing network of projects.
Here’s what it might look like:
Some time in the far future (by Internet time,) you decide you’re going to make a program to recognize chess piece arragements, given a digital image taken from the physical world of a chess board and pieces on it.
You check Google, looking for “chess visualization project.” You see some projects that have been dedicated to rendering 3D imagines of chess pieces, given a machine representation of a board. But, you want something that goes the other way- you want to make something that takes digital images from the physical world, and turn them into the machine representations of the board.
So, you look at the project you found from the perspective of the ProjectSpaceNetwork.
You push the right keys, and you see the network, centered on this particular chess visualization project. At the default level of detail, you see the facts of this particular project: VoiceOverInternetProtocol channels that it uses, video channels that it uses, real-time edit document stores (modern day wiki), links to people who are involved in the project (highlighted if they are available for correspondence on this project right now), etc., etc., etc.,. It’s all in a beautiful non-rectilinear futuristic interface. Very nice.
We can imagine something like:
Now, you zoom out a bit, and find that it’s part of a network of projects, visualized in a TensionMap. Nearby is a project related purely to the creation of models for chess pieces. Further away, you can see, in the distance, myriad projects related to teaching the game of chess, both to humans and to machines (automatic code-installers, best-play or best-for-training lookup-servers, etc.,etc.,.). You can also see projects related to the mapping of the history of chess, projects keeping stats on major chess games, projects keeping representations of chess games, etc., etc.,. But that’s all looking too far.
You also notice that nearby, there’s a project dedicated to just what you wanted to do! It’s a project dedicated to the visual analysis of chess board photographs, in order to make machine representations of chess board configurations.
You travel over to that project (by clicking on it’s node), and zoom in on it. It looks like there’s only 1 or 2 people casually working on this project, and 3 or 4 people casually observing. They have a status blog, a document respository, a source code repository, a mailing list, etc.,. You plug yourself in as an interested casual observer, subscribe to the blog, and start looking through the source code repository.
You realize that some of these concepts are too deep for your immediate level of understanding. No problem- you just zoom out, and see what projects are in the neighborhood. Sure enough, there’s a few visualization communities nearby. One is producing a hypertext on visualization on computers in general, one is a place for more general communication and coordination over visualization projects. It seems that the ProjectSpaceNetwork around the chess projects wiki has also linked to some library projects that it uses, and some specific reference maintenance projects.
This is the “ProjectSpaceNetwork.”
Anyone who wants to work on anything goes into the network, and looks for projects that look like a close-enough match, explore the territory, learn what’s available, and goes to work on what they like. The network is maintained by the nodes. That is: The particular nodes take care of their own particular space, and make agreements (generally implicit, but some times explicit) between each other on how to link together, what to accept, what not to accept, etc., etc.,. Some chunks of the ProjectSpaceNetwork are highly formalized, with clear procedures for determining what is linked and not. The vast majority is very casual: “Does this link that someone added look good? Let’s keep it. Oh: This looks like a spammer, or something. Toss that link.”
When you start a new project, you just create whatever is needed to make the project’s node, link in the project resources, and then link your project up with the neighboring projects, and you link from theirs to yours. If they don’t think your project is relevant, or you’ve positioned your project too “close” to theirs, or even too far away, they’ll correct it themselves, by their own process.
What does this network do for us? It makes us highly aware of what projects are going on in the immediate vicinity. We learn very easily when a related project, that we would care about, appears. It is localized to likely interest. It is not based on key-word, which means that if people use different words for the same things, they are still (likely) connected. It is also something that helps create community, because people who are interested in what each other are interested are likely to discover each other, and create a relationship between themselves. The ProjectSpaceNetwork contributes to the InternetConcentration, and forges a SharedAwarenessSystem.
The wiki nodes network focuses exclusively on wiki, to help people find publicly editable document resources, that they can listen to or contribute on right away.
There are three basic needs, to make a working ProjectSpaceNetwork.
Wiki can actually fulfill these needs in a primitive way. The WikiNodes:WikiNodesNetwork can be seen as an early version of the ProjectSpaceNetwork. It is elegant because wiki naturally brings data, visualization, and editing together. It is primitive, because it’s all text, looks different everywhere, and is hard to edit.
A more likely candidate for data is the SemanticWeb. [[DOAP?]] ("Description of a Project") is a project that to gives sem-web language for describing projects. So, you can say: “Here’s a project, it’s called foo, it’s webpage is blah, and it has these project members.” Some people describe it as “FOAF for projects.” It does not support pointing to related projects, but because of the way the SemanticWeb works, other people (perhaps you?) can write the language to relate projects to one another.
Now, there’s no editor on DOAP. If someone enterprising wanted to, you could take the MachineCodeBlocks or WikiFormats idea, and scrape wiki for specially formatted data. Then construct DOAP entries from them. Ta-da, instant project descriptions. Or, just write a proper DOAP (& other stuff) editor.
Of course, this all means nothing if we can’t visualize it all. What will the visualization look like? It could be a “balls and sticks” model, like in the diagram above, or a yellow-pages like listing, or some other sort of MacroScope?. It’s not clear yet how it will turn out. But there needs to be some way of seeing related projects. The UserInterface? for any particular ProjectSpace visualization application should be consistent (contrast with the WikiNodes:WikiNodesNetwork, which is “viewed” via multiple different WikiEngines?; hence the user interface changes as you view different nodes).
We think it is likely that more mediums will perform like wiki: They will be interactive, feature ActivityAwareness? / public presence, that there will be public editing, lots of collaboration, smooth permission systems, both SoftSecurity and HardSecurity? as norms. That is, that we (humanity) will make a DevelopersVirtualWorld.
One feature that would eventually be nice would be to be able to pull neighboring projects’ SVG maps, and then to be able to morph and shape them for your particular view.
Here are some pictures we have seen, collected, that are related.
Hello, I’m Vinay Gupta, the person who made the Gupta Option map. I’m interested in your project and its progress, I could really use some tools like that for keeping track of all my friends - that’s why I made the manual version you linked. email@example.com please be in touch as things move fowards. Ta, Vinay.
Hi. One question. How are you dealing with information organization and retrieval(categorizations of terms, semantics, lexical ambiguities, properties inheritance, the human factor which is one projects cornerstone, ecc) ? Thanks. Faithfully. JeanmarcRaina?
The ProjectSpaceNetwork, as imagined above, thrives on ambiguity. That’s because it’s informal and analog.
For the purposes of explaining, I’ll divide catalog services into three types:
I think we’ve put way to much emphasis into both formal descriptions, and discrete descriptions.
Informal, analog, and (as we gain the technology) inferred descriptions are very useful.
Now, the ProjectSpaceNetwork above has formal elements: There is an idea that there is a list of chat rooms, a list of formal project members, etc., etc.,. We can make categories to store that kind of information, and stuff.
But there is also, in this imagination of the ProjectSpaceNetwork, informal and analog information attached.
For example: How close does the Chess Visual Recognition project consider itself to be to the general Visual Recognition Studies project? What about the little micro-projects nearby- how close are they?
How important does it consider other projects to be, relative to itself?
What is the preferred positioning of other projects, relative to itself?
These are analog relationships. They are not specified with a category. Rather, they are represented by floating point values.
Right now, if you catalog a project on FreshMeat, you go through this process where they present a bunch of categories, and you say, “I belong to this one, this one, this one, this one, and that one.”
With the ProjectSpaceNetwork as imagined, you would set up “sympathies” between projects, as well. Analog sympathies: You can drag a slider, showing how much tension you think there is between the two projects. We don’t have to completely discard formal categories, but I think that the human analog information is much more useful.
You can also position things, spatially, and play with these tensions and arragements that way.
(This is, to a large degree, connected with why I choose paper over computer notebooks. On paper, you can write sloppy, you can write nice, or any gradient in between. (This communicates useful information!) On paper, you can make text as big or small as you like, with ease, and with incredible power over presentation. On paper, you can spatially position with ease. On paper, you can do all these analog things extremely easily. But this is all another discussion.)
Does this help explain?
While thinking about types of charts that might go on CommunityWikiProgrammingProjectPriorities, I realized that the sort of information that I was listing there is the same sort of thing that ProjectSpaceNetwork would capture. So, for later reference, I’ll list here some elements that should be in the DOAP & ProjectSpaceNetwork ontology:
Here is how these things interrelate. Developers contribute to projects. Developers have a technical agenda consisting of goals. Projects help to fulfill these goals. Projects also depend upon the fulfillment of other goals by other projects.
There is also a lot of structure between entities of the same type. Individuals work together and respect one another. Projects have similarities to “nearby” projects. Goals are similar to other goals, and may be contained in each other (i.e. goal A might be a subgoal of goal B).
More details on how these different types of entities interrelate:
Individuals work on projects and they also have opinions about projects, such as how useful they think various projects are, how highly they prioritize working on those projects, and how much they wish other people would work on those projects, even if they have no intention of working on those projects themself.
Individuals also have more general technical agendas, which are composed of “goals”. For instance, “wiki interoperability” might be a goal. “Make wikis easier to use” might be a goal. Goals might also be more specific; “translate MediaWiki? markup into UseMod? markup”. Individuals’ opinions about goals might be complex the same way their opinions about projects are; they might have priority lists of goals, etc. Presumably, individuals tend to contribute to projects which serve their goals.
Projects (attempt to) advance broader goals. For instance, WikiGateway attempts to improve “wiki interoperability”.
In addition, projects are helped by the achievement of other goals (dependencies), and the developers of those projects may be interested in developments along those fronts; for instance, in writing WikiGateway, I used a library which allowed a Python client to handle WWW forms. So, if other projects appeared which did a better job of serving the goal of “WWW form handling in Python”, I’d want to know about them so that I could consider switching.
So, the relation between projects and goals may be like “provides” and “depends” in Debian packages; some projects provide certain goals, and others depend upon the same goals. Developers of a project providing certain goals will be interested in other projects providing the same goals (their “competitors”, with whom they may want to collaborate), in other projects which provide goals that they depend on, and in projects which depend on the goals that they provide (their users).
In addition, developers will be interested in finding other developers with similar goals (to work with them), and in other projects that serve the goals that they desire (maybe they want to join those projects).
Hi. I’m CharleyQuinton
WikiProjectCentral and the WikiProject group are basically Wikipedians and Wikimedians who desire to look outside of the box for ideas that focus on building Communities of Interest. The fundemental principles, rationale, goals and ideals are being developed from a WikiPedia encyclopedic reference project about Community at the Community Builders Taskforce which is itself a Wikipedia WikiProject. I’ve been talking with LionKimbro and MattisManzel on the new #wikiproject channel on FreenodeIRC irc.freenode.net
I think there exists a good solid field of common interest here and perhaps some positive collaboration and expansion of project-focused work can happen. Please feel free to get envolved as you see fit. Thanks in advance!
How to generate a map of projects/communities (wikis) using existing tools. Spider the SwitchWiki? pages, download some articles from each Wiki, extract keywords like it’s done at http://yahoo.theherrens.com/, then cluster the resulting links like it’s done at http://laurie.informatik.uni-bremen.de/clusty/ (or on another site that generates delicious catalogue automatically).
This feels like an idea whose time has come. I’ve been thinking about this for a while myself and am looking to get involved. By the way Lion, I’m in Portland OR near your neck of the woods.
Charles Petrie, in part of the article Emergent Collectives for Work and Play is thinking about this too:
“A contributing technology might be social networks. Suppose that you use these networks of trust to find partners in some new enterprise, whether to build a new Burning Man camp, or develop a new start-up? Or further out, suppose that none of you have a project in common, but as each person works on his/her individual project, there are pieces of information that would help one of your friends with their own project? Now you are engaged in collective work.
You may all be working on designing parts of the next space shuttle. Or you may each be writing a novel. Your design for thermal insulation, or the research you do on eighth century architecture may be of use to some one else. Technologies for facilitating such information sharing for mutual benefit is a natural future step in the increasing sophistication of Emergent Collectives.”
Using SemanticWeb technologies (or perhaps TopicMaps), we could create a distributed formal ontology of project topics. With SemanticWeb, each project could define new terms in the ontology (that is, new topics) and relate them to the terms defined by other projects. This same idea could be applied to WikiNode. For example, maybe the DOAP project could define the term “project”, and the W3C could define the term “network”. Then, the ProjectSpaceNetworkBrowser? project could define the term “project space network” as a “network of projects”, referencing the term “project” which had already been definied by the DOAP guys and the term “network” as defined by the W3C.
The “words” could be referenced by URIs.
If two projects independently defined “network” (i.e. there are two different URIs which are both intended to correspond with the English concept of “network”), then no worries, a third party which discovers that fact could use SemanticWeb language1 to formally express the fact that they are identical.
Now, for example, the BuddySpace project could define itself as a “location-aware Jabber client”, referencing the word “Jabber” (presumably a URI defined by the Jabber guys) and “location-aware” (maybe defined by SmartMobs?).
The advantage of doing things this way (rather than just using English) is that, for example, when the Jabber guys define “Jabber”, they can specify that it can be used for instant messaging, and that instant messaging is a form of chat, which is a type of (primarily) textual real-time communication. Then someone can define IRC as a type of chat, also. And now a ProjectSpaceBrowser? would be able to infer the relationship between Jabber and IRC – furthermore, someone searching for “location-aware chat” could find BuddySpace, even if BuddySpace never used the word “chat” in their description.
Using A.I. natural language processing techniques, you can scan the internet and infer these same sort of relationships between English words (i.e. infer that “chat” and “Jabber” are connected). But somehow it seems cleaner to explicitly express that in machine-readable form.
Why? I’m imagining a set of standarized data structures, starting with [[DOAP?]] and building in other capabilities for representing types of relatedness between projects and for referencing SVG maps (including saying which nodes on the map correspond to which parts of the data structure).
There could be multiple applications for viewing and manipulating the data and the accompanying SVG, though, each with their own UserInterface?.
Right. I don’t disagree.
I’m just saying: An app for viewing the ProjectSpaceNetwork will be internally consistent, in how it presents the places.
Not like the WikiNodesNetwork?. In the wiki nodes network, every place looks different. Very little consistency. Little that can be done about it.
ProjectSpace reminds me of Grokker, which used to be made by Groxis. It’s defunct now, but here’s a screenshot:
thienthanbongtoi vtvn translated this page into Vietnamese, thanks. I moved the Version over to the page ProjectSpaceMultiLingual to continue.
The TouchGraph? browser is pretty amazing btw. I whish it would be less wikipedia centered.
When I have more time, I’d like to link in the image from this page: