[squeak-dev] mailing list VS semantic desktop

Paul D. Fernhout pdfernhout at kurtz-fernhout.com
Tue Jan 27 02:23:44 UTC 2009


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.



More information about the Squeak-dev mailing list