Ignacio-
Thanks for the reply.
I too don't see this as a switch to happen any time soon. :-)
That's an interesting point you raise about how a community functions and how someone jumps into it in a constructive way. Wikis are less obtrusive in a way. In a sense, a Social Semantic Desktop might be conceptually somewhere between a wiki with lots of pages each with a discussion and a mailing list with just one stream of discussion (although with topical threads that usually last at most a few day).
In an SSD (at least how I envison it) you'd essentially be modifying shared objects which were used by various applications (to put it in OO terms). (Though I'd personally implement it as triples, because I'm very concerned about things like the history of the change of a value of an attribute of an object, so I like the idea of such a change being a reified thing I can refer to, not an afterthought squirreled away in a log that is only accessible in arcane ways.)
What the applications were on top of that is a complex question and probably the subject of much future innovation.
In a way, the deeper issue you raise is how the social dynamics of a group maps on to the software infrastructure it uses or builds for itself. And as the group's needs change, the software would need to change to. But, ideally you want a distributed platform flexible enough to allow for all sorts of changes.
A related web page on social software design and some excerpts (but the whole thing is worth reading): "A Group Is Its Own Worst Enemy" http://www.shirky.com/writings/group_enemy.html """ In particular, I want to talk about what I now think is one of the core challenges for designing large-scale social software. Let me offer a definition of social software, because it's a term that's still fairly amorphous. My definition is fairly simple: It's software that supports group interaction. I also want to emphasize, although that's a fairly simple definition, how radical that pattern is. The Internet supports lots of communications patterns, principally point-to-point and two-way, one-to-many outbound, and many-to-many two-way. ... Nevertheless, I think that definition is the right one, because it recognizes the fundamentally social nature of the problem. Groups are a run-time effect. You cannot specify in advance what the group will do, and so you can't substantiate in software everything you expect to have happen. ... People who work on social software are closer in spirit to economists and political scientists than they are to people making compilers. They both look like programming, but when you're dealing with groups of people as one of your run-time phenomena, that is an incredibly different practice. In the political realm, we would call these kinds of crises a constitutional crisis. It's what happens when the tension between the individual and the group, and the rights and responsibilities of individuals and groups, gets so serious that something has to be done. And the worst crisis is the first crisis, because it's not just "We need to have some rules." It's also "We need to have some rules for making some rules." And this is what we see over and over again in large and long-lived social software systems. Constitutions are a necessary component of large, long-lived, heterogenous groups. """
That essay also mentions barriers to entry being a *good* thing.
Again from the above link: "3.) Three, you need barriers to participation. This is one of the things that killed Usenet. You have to have some cost to either join or participate, if not at the lowest level, then at higher levels. There needs to be some kind of segmentation of capabilities. Now, the segmentation can be total -- you're in or you're out, as with the music group I just listed. Or it can be partial -- anyone can read Slashdot, anonymous cowards can post, non-anonymous cowards can post with a higher rating. But to moderate, you really have to have been around for a while. It has to be hard to do at least some things on the system for some users, or the core group will not have the tools that they need to defend themselves. Now, this pulls against the cardinal virtue of ease of use. But ease of use is wrong. Ease of use is the wrong way to look at the situation, because you've got the Necker cube flipped in the wrong direction. The user of social software is the group, not the individual. I think we've all been to meetings where everyone had a really good time, we're all talking to one another and telling jokes and laughing, and it was a great meeting, except we got nothing done. Everyone was amusing themselves so much that the group's goal was defeated by the individual interventions. The user of social software is the group, and ease of use should be for the group. If the ease of use is only calculated from the user's point of view, it will be difficult to defend the group from the "group is its own worst enemy" style attacks from within. "
So, that suggests that if to get the most out of the Squeak discussions required using applications running on Squeak, that might actually be a good thing.
Anyway, there is more I could say on the pros and cons of using a triple store for this instead of a real multi-user OO database like Magma, but I'll won't go into that for now, and I might be wrong. Essentially, though, beyond the reification issue for changes mentioned above, I think social software could be more fault-accepting of lost information (if you are missing something, or something doesn't work right, you could ask someone for help), and that different emphasis then opens up some possibilities for simpler approaches that are more flexible and less likely to have bottlenecks.
Already, as I look at how Squeak is currently supported, with lots of mailing lists and web sites, I can wonder how much better if all that was integrated in some Squeak applications that somehow collaborated easily (like integrating Monticello and the SqueakDev mailing list somehow). I know that may sound silly at first -- Monticello is for package management, the Squeak list is for discussions, yet obviously, most of what is being discussed relates to what Monticello is used for in some way, so one might imagine closer integration somehow. There are a lot of Squeak-related lists now, and again, maybe those might somehow be more tightly coupled to content on various wikis (even though you view one with an email client and the other with a web browser).
Anyway, I guess I am not clear on what I mean, and maybe I'm not sure completely what I mean, :-) but in general I'm saying one can try to imagine some sort of community-oriented environment in Squeak that was more integrated than using web browsers, email clients, IRC, and Monticello etc. to work together. Frankly, I'm not sure what that would look like, and I expect both at first and most frequently it would not look a whole lot different inside of Squeak from using these separate applications. But what I am hoping for is that using a common backend of a distributed RDF-like triple store database, that new possibilities would be thought of for integration. One obvious example is moderation -- one might select "Newbie" mode and all but the most basic packages and discussions might just be hidden or grayed out (other than one some moderator deemed appropriate for beginners). Or when you looked at a note that discussed some package, the package information might automatically show up in another window with its revision history. Or when someone discusses a bug report, you could click on something to get the bug reporting tool, which you might drag a screen shot image into.
I really don't know what it all would look like; I'm just sensing a potential there when one thinks of, as Clay Shirky suggests, the user being the community and not an individual.
But, I know this goes against the grain for some, because back years ago on the defunct list for the first try at a Squeak Foundation there was some disagreement about whether Squeak should emphasize being a person computing platform or a collaborative computing platform. What I'm talking about here, generalized, would really be about pushing Squeak way more into a collaborative computing direction (especially for discussing itself).
And certainly Squeak has already gone there several times like with Croquet or Seaside or Nebraska. But somehow I feel those have lacked the generality of infrastructure a distributed triple store might provide. I know, people are probably already saying it should be a distributed object database -- and to some extent one is interchangeable for the other in theory -- it's more a matter of emphasis. I might well be wrong on this and the Squeak community might be happier with something that looked more conventionally OO.
Thanks again for your interest, and any more feedback is appreciated.
--Paul Fernhout
muyuubyou wrote:
I think this switch would be a bit too radical when we haven't even made it to "forums" yet ;)
Mr. Fernhout, your proposal is extremely interesting and I'm looking at it right now.
I wonder how hard would it be to integrate with the mailing list, to have a number of monthly, weekly or daily abridges messages explaining the changes in the semantic desktop (or even in the forums!) with different levels of detail.
Squeak is difficult to follow like this. I've been in this ML for years and I barely participate because I'm always afraid I'm going to repeat a topic or spam people with a largely uninteresting topic. In other words, I know it's intrusive to get into people's mailboxes which is why more often than not I just shut up.
Please, let's have some less intrusive system to participate. I always wanted to discuss traits yes or no, Nile, the future VM, ... and never did because I know here there are many "giants" that I cannot bother with my opinion.
Regards. Ignacio S.