Language and Adolescence

Penelope Eckert, Professor of Linguistics at Stanford, gave a talk entitled, “Language and Adolescence,” this afternoon at the PARC Forum. Eckert explained the role that adolescent language played in developing peer social order, and dispelled complaints that teenagers were hurting language by using it irresponsibly. Her theories are based on extensive ethnographic studies of junior high school students in Detroit and the Bay Area.    (7E)

I went to this talk for two reasons. First, I couldn’t pass up the opportunity to hear an academic lecture on “jocks” and “burnouts.” Eckert clearly enjoyed emulating various teenage and adult speech patterns, and garnered many giggles throughout her talk. Second, I’d like to eventually recruit a sociolinguist to Blue Oxen Associates, and wanted to get a sense of what such research entails. What do language patterns reflect about communities? What do we already know, and what remains to be studied?    (7F)

Eckert claimed that adolescents are leaders in linguistic innovation, which reflects their efforts to find their place within a structured social marketplace. She found a high correlation between various roles (e.g. “drama queens,” “onlookers,”) and certain speech patterns. According to Eckert, over 50 percent of the kids she studied were either “jocks” or “burnouts.” The latter group exhibited unique speech patterns. For example, burnouts were far more likely to use Negative Concords (e.g. “That don’t mean nothing”) than jocks, an act of rebellion against socially imposed institutions.    (7G)

Eckert has written several books about her research, including Jocks and Burnouts and Linguistic Variation as Social Practice.    (7H)

Sociolinguistic Analysis    (7I)

Identifying who plays what role in a community, or whether or not a person is a member of a community, is a difficult problem. I posted some ideas on this in January, where I argued that individuals mostly categorize themselves. I asked Eckert what criteria she used to categorize people as jocks or burnouts. She said that the students categorized themselves. She had some socioeconomic data that she could use to challenge the self-categorization, but found that she never needed to do so.    (7J)

Eckert’s talk reiterated my awareness of the sensory richness of face-to-face communication. Speech nuances alone carry a tremendous amount of information. Sadly, these nuances don’t exist in online communities. What affect does this loss of sensory richness have on online communities? Do online interactions have their own kinds of richness that face-to-face interactions do not share?    (7K)

Applying sociolinguistic research towards online communities would require analyzing patterns in writing. I believe we could learn a tremendous amount about communities through this kind of analysis. If anyone knows of such research, please let me know.    (7L)

Blue Oxen Trivia    (7M)

There are a number of good public talks held at PARC’s George Pake Auditorium in Palo Alto. In fact, I met half of the Blue Oxen Associates advisory board there. I first heard Doug Engelbart speak at the BayCHI meeting on December 10, 1996. I first heard Richard Gabriel speak at the Software Development Forum meeting on January 23, 2003.    (7N)

Groupware Patterns Wiki

Seb Paquet points to the Groupware Patterns Wiki.    (7B)

I had lunch with Richard Gabriel, one of our advisors, on Monday. Richard is one of the foremost interpreters of the Pattern Language concept, and is president of the Hillside Group, which organizes the Pattern Language of Programs (PLoP) workshops. One of the things we discussed was how the theory underlying pattern languages requires many different communities exploring patterns together. Most existing patterns work seems to happen in relative isolation. To some extent, Hillside fosters intercommunity exploration of patterns, but it wants to increase its activity in this area.    (7C)

So does Blue Oxen Associates. If the pattern work we do is to be effective, it cannot be done in isolation.    (7D)

Purple Metadata in Blosxom

PurpleWiki supports document metadata. The metadata is stored at the beginning of the document using the following syntax:    (6Y)

  {name value}    (6Z)

Currently, PurpleWiki supports the following metadata:    (70)

All of this metadata is available to blosxom via the purple plugin under the $purple namespace. However, I’d also like to override blosxom’s mechanism for determining an entry’s title and date.    (77)

Sadly, overriding the title mechanism is not possible via plugins, and overriding the date would be extremely inefficient. Blosxom assumes that the first line of a file is the title and the rest is the body. This parsing happens before story() is called. This works fine, but it means that the raw file itself can’t be a pure PurpleWiki document. If blosxom instead passed the raw file and delegated the responsibility for parsing title and body to story(), then anyone would be able to customize this behavior via plugins.    (78)

I also wanted to duplicate the behavior of the entries_index_tagged plugin using PurpleWiki‘s metadata. The way entries_index_tagged works is to compare the current directory tree with a cached tree. If there are discrepancies, entries_index_tagged scans the file for a meta-creation tag. If the tag exists, it uses that information; otherwise, it stats the file for its creation date.    (79)

I could easily pass the file to the PurpleWiki parser to scan for the creation date, but the PurpleWiki parser is expensive, and the parsed file would not be cached. If I opted to use an entries_cache approach instead, where the comparison only happens once an hour, then maybe it wouldn’t be too much of an issue. However, I don’t want this feature badly enough to do this, and frankly, the inefficiency of doing it this way gnaws at me.    (7A)

Purple Numbers and Link Integrity

Danny Ayers is looking to implement Purple Numbers in his Wiki, and had the following question:    (66)

But is the expectation that the anchor will always refer to the same information item?    (67)

If we’re going for coolness, I think this may cause problems in the context of Wikis. Ok, pages come and go but the URI will (usually) always address something sensible – edit new page if the one originally addressed has gone.    (68)

But the Purple anchors are pointing to info-snippets that may be modified (no problem – it’s still conceptualy the same item) or be deleted (problem).    (69)

The expectation is that the information to which an anchor points may change. This is obviously not ideal.    (6A)

In March 2001, I wrote some notes for the Open Hyperdocument System entitled, “Thoughts on Link Integrity.” I had posted those notes to a mailing list, but those archives no longer exist, so I reproduce those thoughts below.    (6B)

Danny also mentioned using trackback as an aggregator of comments. There is such a system, which Chris Dent also mentions in his response: Internet Topic Exchange. We used it for the 2003 PlaNetwork Conference to aggregate blogs about the conference.    (6C)

Thoughts on Link Integrity    (6D)

We want the OHS to maintain link integrity across all documents. In other words, once you create a link to something, it should never break.    (6E)

The first requirement for link integrity is that documents are never deleted from the system. If you link to a document, and that document is subsequently removed, the link breaks. The only way to fix that link is to put the document back into the system.    (6F)

The second requirement is to have a logical naming scheme that is separate from the physical name and location of a document. On the web, if you have the document http://foo.com/bar.html, and you move it to http://foo.com/new/bar.html, links to the first URL break. You need a name for that document that will always point to the right place, even if the document is physically moved to a different part of the system.    (6G)

The third requirement is version control. This is where things start to get a little hairy. Version controlled systems are insert-only. In theory, nothing is ever removed. This satisfies the first requirement.    (6H)

However, in a useful DKR, links don’t just not break, they also evolve. Suppose you have a document, foo.txt, that contains the following text:    (6I)

  These are the dasy that try men's souls.    (6J)
  Example. foo.txt, version 1.    (6K)

Note that there’s a typo — “dasy” should be “days.”    (6L)

Now suppose someone creates a link to this sentence in this version of the document. Suppose that afterwards, you notice the typo and correct it. This results in a new version of the document:    (6M)

  These are the days that try men's souls.    (6N)
  Example. foo.txt, version 2.    (6O)

If your links neither broke nor evolved, then the original link would continue to point to version 1 of the document, not this new version. However, this does not always seem to be desirable behavior. If I created a link to this sentence — essentially designating it interesting and relevant content — when the typo is corrected, I’d prefer that the link now point to the corrected document, version 2.    (6P)

This is certainly doable. The system could automatically assume that the link pointing to the first sentence in version 1 should now point to the first sentence in version 2.    (6Q)

However, there are two scenarios when this would not be the correct behavior. First, what if, instead of fixing the typo, the sentence was changed to:    (6R)

  Livin' la vida loca.    (6S)
  Example. foo.txt, version 3.    (6T)

If the purpose of the link is to designate the target content as relevant, then the content of the first sentence of this third version no longer applies, because the meaning of the sentence has completely reversed.    (6U)

Second, what if the link is from an annotation that says, “There’s a typo in this sentence”? In this case, you would want the link to point only to version 1, since the typo does not exist in version 2 (and, for that matter, in version 3).    (6V)

How can we accomodate these scenarios? One solution would be to allow the user to define how the link should evolve with new versions of the document. So, for example, you could specify that the link that points to the first sentence in version 1 should also point to the first sentence in some number of subsequent versions of foo.txt.    (6W)

Another solution would be to have the system automatically notify everyone who has linked to a document (or who has otherwise registered for notification) that the document has changed, and have those people manually update their links, possibly providing suggestions as to how to update the links.    (6X)

OHS Launch Community: Experimenting with Ontologies

My review of The Semantic Web resulted in some very interesting comments. In particular, Danny Ayers challenged my point about focusing on human-understandable ontologies rather than machine-understandable ones:    (5D)

But…”I think it would be significantly cheaper and more valuable to develop better ways of expressing human-understandable ontologies”. I agree with your underlying point here, but think it’s just the kind of the Semantic Web technologies can help with. The model used is basically very human-friendly – just saying stuff about things, using (triple) statements.    (5E)

Two years ago, I set out to test this very claim by creating an ad-hoc community — the OHS Launch Community — and by making the creation of a shared ontology one of our primary goals. I’ll describe that experience here, and will address the comments in more detail later. (For now, see Jay Fienberg’s blog entry, “Semantic web 2003: not unlike TRS-80 in the 1970’s.” Jay makes a point that I want to echo in a later post.)    (5F)

“Ontologies?!”    (5G)

I first got involved with Doug Engelbart‘s Open Hyperdocument System (OHS) project in April 2000. For the next six months, a small group of committed volunteers met weekly with Doug to spec out the project and develop strategy.    (5H)

While some great things emerged from our efforts, we ultimately failed. There were a lot of reasons for that failure — I could write a book on this topic — but one of the most important reasons was that we never developed Shared Language.    (5I)

We had all brought our own world-views to the project, and — more problematically — we used the same terms differently. We did not have to agree on a single world-view — on the contrary, that would have hurt the collaborative process. However, we did need to be aware of each other’s world-views, even if we disagreed with them, and we needed to develop a Shared Language that would enable us to communicate more effectively.    (5J)

I think many people understand this intuitively. I was lucky enough to have it thrown in my face, thanks to the efforts of Jack Park and Howard Liu. At the time, Jack and Howard worked at Vertical Net with Leo Obrst, one of the authors of The Semantic Web. Howard, in fact, was an Ontologist. That was his actual job title! I had taken enough philosophy in college to know what an ontology was in that context, but somehow, I didn’t think that had any relevance to Howard’s job at Vertical Net.    (5K)

At our meetings, Jack kept saying we needed to work out an ontology. Very few of us knew what he meant, and both Jack and Howard did a very poor job of explaining what an ontology was. I mention this not to dis Jack and Howard — both of whom I like and respect very much — but to make a point about the entire ontology community. In general, I’ve found that ontologists are very poor at explaining what an ontology is. This is somewhat ironic, given that ontologies are supposed to clarify meaning in ways that a simple glossary can not.    (5L)

Doug himself made this same point in his usual ridiculously lucid manner. He often asked, “How does the ontology community use ontologies?” If ontologies were so crucial to effective collaboration, then surely the ontology community used ontologies when collaborating with each other. Sadly, nobody ever answered his question.    (5M)

OHS Launch Community    (5N)

At some point, something clicked. I finally understood what ontologies (in an information sciences context) were, and I realized that developing a shared ontology was an absolute prerequisite for collaboration to take place. Every successful communities of practice had developed a shared ontology, whether they were aware of it or not.    (5O)

Not wanting our OHS efforts to fade into oblivion, I asked a subset of the volunteers to participate in a community experiment, which — at Doug’s suggestion — we called the OHS Launch Community. Our goal was not to develop the OHS. Our goal was to figure out what we all thought the OHS was. We would devote six-months towards this goal, and then decide what to do afterwards. My theory was that collectively creating an explicit ontology would be a tipping point in the collaborative process. Once we had an ontology, progress on the OHS would flow naturally.    (5P)

My first recruits were Jack and Howard, and Howard agreed to be our ontology master. We had a real, live Ontologist as our ontology master! How could we fail?!    (5Q)

Mixed Results    (5R)

Howard suggested using Protege as our tool for developing an ontology. He argued that the group would find the rigor of a formally expressed ontology useful, and that we could subsequently use the ontology for developing more-intelligent search mechanisms into our knowledge repository.    (5S)

We agreed. Howard and I then created a highly iterative process for developing the formal ontology. Howard would read papers and follow mailing list discussions carefully, construct the ontology, and post updated versions early and often. He would also use Protege on an overhead projector during face-to-face discussions, so that people could watch the ontology evolve in real-time.    (5T)

Howard made enough progress to make things interesting. He developed some preliminary ontologies from some papers he had read, and he demonstrated and explained this work at one of our first meetings. Unfortunately, things suddenly got very busy for him, and he had to drop out of the group.    (5U)

That was the end of the formal ontology part of the experiment, but not of the experiment itself. First, we helped ourselves by collectively agreeing that developing a shared ontology was a worthwhile goal. This, and picking an end-date, helped us eliminate some of the urgency and anxiety about “making progress.” Developing Shared Language can be a frustrating experience, and it was extremely valuable to have group buy-in about its importance up-front.    (5V)

Second, we experimented with a facilitation technique called Dialogue Mapping. Despite my complete lack of experience with this technique (I had literally learned it from Jeff Conklin, its creator, the day before our first meeting), it turned out to be extremely useful. We organized a meeting called, “Ask Doug Anything,” which I facilitated and captured using a tool called Quest Map. It was essentially the Socratic Method in reverse. We asked questions, and Doug answered them. The only way we were allowed to challenge him or make points of our own was in the form of a question.    (5W)

That meeting was a watershed for me, because I finally understood Doug’s definition of a Dynamic Knowledge Repository. (See the dialog map of that discussion.) One of the biggest mistakes people make when discussing Doug’s work is conflating Open Hyperdocument System with Dynamic Knowledge Repository. Most of us had made that mistake, which prevented us from communicating clearly with Doug, and from making progress overall.    (5X)

Epilogue    (5Y)

We ended the Launch Community on November 9, 2001, about five months after it launched. We never completed the ontology experiment to my satisfaction, but I definitely learned many things. We also accomplished many of our other goals. We wanted to be a bootstrapping community, Eating Our Own Dogfood, running a lot of experiments, and keeping records of our experiences. We also wanted to facilitate collaboration between our members, most of whom were tool developers. Among our many accomplishments were:    (5Z)

The experiment was successful enough for me to propose a refined version of the group as an official entity of the Bootstrap Alliance, called the OHS Working Group. The proposal was accepted, but sadly, got sidetracked. (Yet another story for another time.) In many ways, the Blue Oxen collaboratories are the successors to the OHS Working Group experiment. We’ve adopted many of the same principles, especially the importance of Shared Language and bootstrapping.    (64)

I believe, more than ever, that developing shared ontology needs to be an explicit activity when collaborating in any domain. I’ll discuss where or whether Semantic Web technologies fit in, in a later post.    (65)