FrontPage SiteMap RecentChanges HowTo Blog

Matching Pages:

RSS

ConversationField

A conversation field is a space for conversation.

Here are the basic ideas:

In the OverHear system, everybody has a conversation field around them.

http://taoriver.net/img/for_cw/ConversationField/001.png

See? There everybody is, with their conversation field around them.

(The terms "field" and "space" are used here interchangably. They mean the same thing.)

Metaphorical inspiration

In Crest Of the Star, when spaceships jump into hyperspace, they carry a bubble of normal-space around them. Before they encounter enemy spaceships in hyperspace, they sense their far-away normal-space. When their normal-spaces touch and merge, they can actually start firing missiles at each other.

Subscription

People can talk into their own conversational field. Because others can subscribe to their field, the net result is that it's something like blogging. You say something, and your subscribers hear it. But with an instant messaging "push" twist.

http://taoriver.net/img/for_cw/ConversationField/002.png

You'd likely subscribe to your friends' fields. If they had something to say but to nobody in particular, they'd just speak it into their field, and you'd hear it.

Merging Fields

One thing that is kind of interesting, is that people cannot enter each other's conversational field. For example, if Alex Schroeder has a conversation field around him, you can't walk into it.

What happens instead, is that, if you want to talk with Alex, you merge your fields. At least temporarily.

http://taoriver.net/img/for_cw/ConversationField/003.png

  1. You have a field.
  2. Alex has a field.
  3. You send a first message to Alex.
  4. Alex responds to the message, confirming the merging of fields.
  5. You have now effectively merged you twos' fields.

In reality, the "merged field" is it's own field, and we've just pointed the two of you's fields to point to a new field.

http://taoriver.net/img/for_cw/ConversationField/004.png

But we call it "merged," because we want to describe the situation for subscribers.

The people who subscribed to Alex's field- they now hear everything that is happening in your conversation. The people who subscribed to your field- they now hear everything that is happening in your conversation.

That's part of why the system is called "overhear."

http://taoriver.net/img/for_cw/ConversationField/005.png

This way, you can hear all the conversations that your friend is partaking in!

Let's take an inventory of what we have so far:

Development and Fragmenting of Conversations

About that last point- jumping in. When people are engaged in a merged conversation, you can send a note to the shared space. (I'm not worried here about the particulars of how joining the conversation works.) Your conversational field then merges with the spared space. You are now a part of the conversation.

http://taoriver.net/img/for_cw/ConversationField/006.png

It's my belief that a lot of larger conversations will actually come about this way- a friend of yours has a conversation with someone, and you overhear it. It sounds interesting, and you find you have something to contribute. You send a message, and suddenly you are three.

There's a network effect here: Suddenly all of your friends are overhearing the larger conversation (via their subscription to you,) and now they are interested, and want to say something. The party grows larger.

http://taoriver.net/img/for_cw/ConversationField/007.png

At some point, the group gets large enough that they want to split into individual conversations. The conversation splits into fragments (by some mechanism,) and now there are lots of little conversations.

Perhaps the mechanics of OverHear allow for some networking between conversations. History tracking, something like that - so that you can see how conversations came about, and find the earlier or later conversations.

Perhaps you could have some sort of cool conversation visualizer, for hopping around.

http://taoriver.net/img/for_cw/ConversationField/008.png

Maybe superfluous, but this diagram helps us understand how conversations develop and fragment.

So, we have:

Pegs

There's only one major thing really missing: topic based arrangements.

Right? For example, in IRC, we can group ourselves by topic. We can say, "I am interested in wiki," and join "#wiki." #wiki is a chat room dedicated to wiki. It is expected that when people talk in #wiki, that the primary conversation be of general interest to the wiki community.

The system we've described, of conversational fields, so far has nothing to account for that kind of interaction.

So, we add a new concept: "Pegs."

A "peg" is something that has a conversational field of it's own, but it's not a human.

(diagram of people and pegs with their conversational fields- all alone, all cut off)

The people in the drawing above are not pegs. But, the squares in the drawing above are pegs.

"Peg" is an English word that means something like a "pin for fastening" or a "hook for hanging" something.

We're going to use the word "peg" to describe a thing that we "hang" our conversations on. When we are talking about a particular sort of ideas, we'll be able to hang our conversation on a relevant "peg."

Let's see it work.

Let's say that there's a peg called "#wiki."

(drawing of a bunch of people, and a peg called #wiki)

If you want to hear about wiki stuff, you subscribe to the "#wiki" peg.

(drawing of a bunch of people subscribed to #wiki)

Now, let's say a bunch of people are talking about wiki. When they realize, "Oh, we're talking about wiki," they pull in the wiki peg.

(drawing of #wiki pulled into the conversation field of people talking about wiki)

Now, we see, all the people who are generally interested in wiki- they see the conversation about wiki.

In this way, we have the same effect of "chat rooms" in IRC.

Pegs can be Bots

We use "peg" in English to mark borders, and we use "peg" in English to talk about "hooking" things together.

But, we also use it to talk about "solid pieces." Like, if you're playing a board game, the pieces on the game board can be called "pegs." If you're playing Monopoly, we might call the boot or the battleship a player's "peg." That would not be too strange.

So, the word "peg" will also suggest "bots." A "peg" in the OverHear system is likely a bot.

Someone would have administrative control over the #wiki bot. That way, if some spammers share space with the #wiki field, the administrator of the bot would lock out the spammer.

Likely, the bot would have an internalized sense of delegating power. Sort of like the "op" system in IRC. The bot owner could say, "MattisManzel has the same powers to control the bot that I do."

Bots would also take care of any logging, could provide general services, etc., etc.,. (See also: TheBot, CommBot.)

Pegs can be URLs

Peg's could be "incarnate URLs," or something like that.

So, if y'all are looking at a page on a [SharedWebBrowser? shared web browser,] hopefully more sophisticated than our venerable low-tech shared web browser, then the shared web browser could invoke pegs for the URLs that are being visited, and bring them into the converesational space.

So groups that are talking around a web page could see each other.

If you just pulled a web browser into your own field (merging fields), then you could be "publishing" your location, and see other people looking at the same "location."

"Conversations": not just words

There's no reason bots can't communicate with each other via the conversational fields. And there's no reason bots couldn't listen in on each other's communications. You could build [IntComm:ActivityAwareness? activity awareness] using the underlying technology for "Conversation Fields."

the end

This is basically all I have to say now, to explain the basic ideas of "Conversation Fields."

This will be a VisualLanguage explanation of a concept originally described in OverHear. The OverHear page is sloppy and hard to follow, I think this wil be a lot nicer.

I'm very busy with work right now, so I don't have time to fill in the pictures for this. I'll be at work for the rest of the day. I intend to fill the pictures in, a bit at a time, over the coming week. Please don't erase the markers for images.

I originally wrote a page while creating the images. Half-way through, I realized a mistake, and had to replace a bunch of stuff. I'm now thinking it's best to make the text first, with place-holders for images, and then make the images afterwards. It takes a long time to make images. (See also: "LongImageIncorporationProcess," on the Visual wiki. When we all have tablets in 5 years, this should be easier on us.)

Sprouts of the technology to implement OverHear are popping up all over the place; The technology is a seperate discussion altogether, after the basic ideas.

I'm still working on LocalNames, but I wanted to take time to write out the ConversationFields? idea.

update: I've added diagrams for all but the peg discussion, which I want to finish soon.

Discussion

I think the word "peg" is confusing. I'm not sure what to replace it with, though. "Topical labels"?

I like "Topical Label" for referring to things like #wiki. But what if it's just a favorite bot? Or some URL? Or some sort of service, like a game, or something like that?

Also, it feels weird to me to say, "I'm subscribing to a label for a conversation." It feels easy to say, "I'm subscribing to a peg for a conversation," though.

Then again, I'm biased. I've been using the phrase "Memory Peg" for a long time now.

As I understand it the model has conversation fields (pegs) and three operations on them subscribtion (which means getting updates in realtime about them), joining (with sending a message to them), and leaving. Each participant has her own conversation field, and additionally there are topical conversastion fields. The quesiton is when you are in one conversation field and you are to join another, does those two fields merge? And then when this participant joining two conversations leave one of them then the conversations split? This would be a bit strange.

merging fields

When two people start talking with one another, their fields merge. Well, it feels like they merge. People who were subscribed to one field now hear everything in the other field. So, it feels like they merged.

It feels like this:

http://taoriver.net/img/for_cw/ConversationField/003.png

In reality, technically, the situation is probably going to be modeled something like this:

http://taoriver.net/img/for_cw/ConversationField/004.png

That is, the individuals' fields point to a new shared field. The shared field poinst back to information about the individual participants.

two conversations at once

If someone participates in two seperate conversations at the same time, then the system should handle that.

The word "merge" is not adequate here.

The person is actually engaged in two distinct conversations. People who subscribe to the person's field, though- they suddenly get two conversations on their radar. That is, they overhear two seperate conversations. Perhaps in the user interface, they see two seperate texts flowing down. They can choose to join one, the other, or both. But they passively experience both conversations.

Should two conversations decide to merge, though, they should be able to do that.

"topical conversations"

Conversation fields don't have "topics." There is no such thing as a "topical conversation field."

Rather, you can pull in a peg, representing a topic. When I'm not entranced by d.taylor, I'll work out diagrams that I think will make the concept of "pegs" clearer. Basically, just take this diagram…

http://taoriver.net/img/for_cw/ConversationField/001.png

…and change some of the icons of people for boxes. The boxes will represent "pegs"- non-humans with conversation fields. They're not a basic type- the technology probably sees humans and pegs alike.

Maybe Bayle is right; Maybe I should have never introduced the word "peg." Just look at the conversation fields, and understand that people and bots and … uh… "markers…" …have their own conversation fields that can be subscribed to. (Hm, marker is no better than peg.)

I mean: A peg could be a word. It could be a url. It could be an anything, basically. I don't really care what it is. Just that it's something that has a conversation field around it, that can be hooked into other conversations.

I'd write more, and make more diagrams, but I'm about to go to bed.

I'd like to make some diagrams of what a UserInterface might look like, too.

Thanks for the answers. I have another question - what is the difference between the subscription and joining the conversation field of another person? From what I've read here in both situations the person just gets all the messages from and to the other person. Perhaps the messages would be displayed differently - but then what would be exactly the difference?

In a word, "Presence."

If you just subscribe, but do not participate, you are a lurker, and an icon indicates that. (Or some other UI mechanism.)

Furthermore, if you are subscribed, but do not participate, your subscribers do not hear what you are listening to.

That is, if C & D are talking with each other, and B is subscribed to C, and A is subscribed to B:

  • B hears C, because B is subscribed to C.
  • B hears D, because C & D's fields are "merged," being that C & D are talking with each other.
  • But A does not hear B, A does not hear C, A does not hear D - A is subscribed only to B, and B's not talking.

Otherwise, as soon as one person started talking with another- Everyone who knew someone who knew someone who knew someone who knew someone who knew one of the participants- would suddenly be part of the conversation. :)

I need to say that I don't like that 'merging fields' metaphore - it suggests transitive closure. There is no real merging.

I would rather call this 'forwarding' - when you subscribe to someone he forwards to you all the messages he receives plus the messages he sends (C forwards to B, length of forwarding path = 1), when you join a him he forwards to you one layer more - that is he forwards to you what is forwarded directly to him (C forwards to B what D forwards to B, length of forwarding path = 2).

I agree that the merging metaphore is a problem. We can huck it.

I don't feel that "forwarding lengths" is the same thing as OverHear.

In OverHear, you only hear:

  • Conversations you are in,
  • and conversations that your friends are in.

By the system you described, there is no differentiation between conversations. You couldn't carry on two seperate conversations, distinct from one another.

Furthermore, by the system you described- if you join a friend, suddenly you are hearing everything that they are hearing. There is no difference between participation and subscription, either, it seems. If they are listening to 3 guys talk that you don't care about, then you have to hear it all.

At least, that's based on what I understand of what you said. Could you draw an ASCII diagram to help explain the system? But it seems to me like it's very different than OverHear.

Actually, Lion, I like "marker" much better than "peg". I just don't think of a "peg" as having any descriptiveness – to me, a peg is something that you hang your coat on, or it's in the "peg game" where you have pegs and holes in the shape of a triangle and you hop some pegs over others and try to leave only one. In both these cases, there is a bunch of pegs, and they're all interchangable; you wouldn't hang your coat on the "presidential politics" peg, etc.

re: previous comment: yes, the system that Lion is describing is indeed different from just forwarding with transitive closure, or with some sort of "distance limit". As Lion said, it's essential that "subscribing" to a conversation is different from actually participating in it (although certainly, some sort of transitive or forwarded subscription mechanism would also be cool). In short, "participating in a conversation" is transitive, and "subscription" is not transitive. If A participates in conversation X with B, and B participates in conversation X with C, then A and C are both participants together in conversation X. But if A subscribes to B, and B subscribes to C, then A is not subscribed to C.

More in a minute..

I think that in the system we've been describing, there may be an implicit distinction between "conversation" and "conversational field". "subscribing" applies to conversational fields, and "merging" applies to conversations. To see if we're on the same page, a semi-formal description:

A conversation is a set of textual events, e.g. "Lion: 'Hello there'", "Zbigniew: 'Why hi, Lion'". If conversation C and D are merged, then from then on (until they are separated), then every textual event in either C or D is in both C and D.

A conversational field is composed of two sets of conversations; a participation set and the lurking set. Each person has (at least one) associated conversational field, and we say that "person P is participating in conversation C" if C is in the participating set of P's conversational field. We say that "person P is lurking in conversation C", or, equivalently, "person P is subscribed to conversation C" if C is in the lurking set of P's conversational field.

If conversation field A is subscribed to conversational field B, then any conversation C in B's participating set also goes into A's lurking set.

So, note that merging is transitive, and subscription is not.

More formally:

Let e represent a conversational event. A, B, C represent conversations. Let f be a function which associates each conversation with a set of conversational events. Let Q, R, and S represent conversational fields. Each conversational field is a tuple (P, L) of two sets of conversations, the participating set, and the lurking set. We write Q_P to denote the participating set of conversational field Q, and likewise Q_L means Q's lurking set.

There is a binary relation merged on conversations. There is an binary relation subscribed on conversational fields.

merged(A,B) iff forall e \in f(A), e \in f(B). The relation merged is symmetric; if merged(C,D) then merged(D,C).

subscribed(Q,R) ("Q is subscribed to R") iff forall C \in R_P, C \in Q_L.

Now, let's consider which relations are transitive. Merged is transitive: if merged (A,B) and merged (B,C), then forall e \in f(A), e \in f(B), and therefore e \in f(C); therefore we may conclude that merged(A,C). However, subscribed is not transitive. If subscribed(Q,R) and subscribed(R,S), then it is quite possible for some conversation C to be in S_P, and therefore in R_L, but not in Q_L.

Lion - I only argued that the length of the path is the differentiating factor, that is you can measure the length of the path and say: I take that message, or I don't take that message. I did not describe any system yet, only a mechanism for deciding if a message is to be received by a participant. You can easily add it to the idea of conversations. But I don't insist on using this vocabulary - you can say that you hear conversations that you are in and conversations that your friends are in - for me it is the same.

I was asking what is the difference between participation and subscription - I wanted you to explain that. In both cases the message is delivered to you. I guess you want to present it differently and I am asking you how.

Bayle's formalization is close, but not quite right. (More in a moment.)

I'm going to use Bayle's distinction between conversation and conversational field. The conversational field represents the person. The conversation represents a group of people talking.

Participation: If you are participating in a conversation, then everyone who is subscribed to your conversational field overhears the conversation.

Subscription: If you are subscribed to a conversational field, then you hear all of the conversations that it is participating in.

In both participation and subscription, you get the messages. But in the case of participation, other people who listen in on you- they overhear you talking. But if you are just subscribed to something, the other people aren't bothered by it.

(I hope this makes it clearer?)

Bayle: I like your formalism! It took a while to get it onto paper and figure it out.

But, I feel it has some problems- I would think that when a conversational field subscribes, it subscribes to another conversational field, not to a specific conversation.

In the language of your formalism, I'd say that a conversational field Q was made of two parts: Q_L (lurking) and Q_P (participating). The difference is that Q_L lurks on both conversational fields and on specific conversations. Whereas Q_P participates in conversations, always. (It doesn't make sense to participate in another conversational field- you can only participate in a full-on conversation with conversational events passing through. Conversational events do not happen in the field.)

I feel that the terms are getting confusing.

Perhaps we should change it like so: Turn "conversational field" into "a person." Let "conversation" be conversation. Turn "subscribes to" into "lurks on." Turn "participates in" into "talks in." Turn "conversational event" into "word."

A Conversation is a thing with words in it. A word comes from a Person, when the Person talks in the Conversation.

A person can lurk on either another person, or on a conversation. A person can talk in a conversation, but a person can't talk in another person. Saying that a person "talks in" another person doesn't make any sense. But saying that a person "lurks on" another person, and that a person "lurks on" another conversation- both of those make sense. (Both to our intuition, and to the formalism.)

Addition: There is always one conversation around a person, which is special because no one else can talk in it. It's called the "thought bubble," and it resembles an IM blog. (Not a major point, but something I'd want to point out.)

So we have:

  • Person (such as Alex, Bayle, Christopher, David)
  • Conversation
  • Word
  • "talks in"
  • "lurks on"
  • Thought Bubble - (a convenience 1-Person Conversation that every Person has)

Person = "Talks in" (some conversations) + "Lurks on" (some conversations and people)

Conversation = bunch of Words, lined up in a row

(We can ignore merging conversations for the time being; Let's just get this basis going first.)

Alex can lurk on Bayle. Bayle can lurk on Christopher. But that does not mean that Alex lurks on Christopher. When Christopher talks in his Thought Bubble, Bayle hears it, but not Alex. If Bayle talks into his thought bubble, Alex will hear it. That's because Alex lurks on Bayle, and Bayle talked in a Conversation- his Thought Bubble.

Christopher and David talk in a Conversation, "C1." I am not naming the Conversation, because that would imply that the conversation has a named topic. Because what people would call a "topical conversation" is made by another mechanism (namely, "pegs" or "markers,") that we're not introducing yet- I don't want to confuse the issue by naming the conversations. So we'll just call them C1, C2, C3.

Bayle hears Christopher and David talk C1, because Bayle lurks on Christopher.

Somehow, Alex learns about C1. Alex does not lurk on either Christopher or David, but Alex decides to lurk on C1. This is a demonstration of Alex lurking on a Conversation, rather than on a Person.

(I hope this makes things clearer? I'll make some diagrams later on to support this.)

OK - that explains it.

Lion: I think that in my formalism you could subscribe to another conversational field; the domain of relation subscribed is conversational fields. However, in the formalism you cannot subscribe to an individual conversation; that is the difference. I know I said

We say that … "person P is subscribed to conversation C" if C is in the lurking set of P's conversational field.

but I was being confusing by using "subscribed" in two ways; the relation subscribed(), and that English interpretation. The relation subscribed() was about conversational fields. The English interpretation could be reworded as follows:

We say that "person P hears (but does not speak in) conversation C" if C is in the lurking set of P's conversational field.

(implementationally, this wouldn't matter; it might be just as easy to have an invisible conversational field attached to every conversation, so that you can seem to subscribe to a conversation while actually subscribing to the conversational field; the conversational field being some sort of URN or address of a data object or something).

Re: a simplified language: "Alex lurks on Bayle" might be confusing. Howabout using "subscribe" throughout instead of "lurk"?

"Alex subscribes to Bayle, so when Bayle talks, Alex hears it".

BayleShanks

OK, here's another attempt to describe the thing clearly in English (not quite identical to my formalism, above):

A "conversation" consists of a bunch of words. Each person can either participate in a given conversation, or overhear it without participating in it, or not even hear it.

Any person can choose to participate in or overhear any (open) conversation.

However, people can also choose to subscribe to other people. If Alex subscribes to Bayle, then Alex automatically overhears every conversation that Bayle participates in.

Conversations can merge. If two conversations C1 and C2 merge, then any words said in C1 are also heard in C2 and vice versa (until such time as they are separated).

Transitivity: So, if C1 is merged with C2 and C2 is merged with C3, then C1 is merged with C3; it's like one big chatroom. However, subscription is different; if Alex subscribes to Bayle, and Bayle subscribes to Christopher, then Alex won't overhear all of the conversations that Christopher participates in.

Topical markers: Just as you can subscribe to a person, you can also subscribe to a topical marker. For example, "#wiki" might mark any conversation having to do with wikis. You can "subscribe" to #wiki just like you can "subscribe" to Alex, and if you do so, you will overhear all conversations about wikis. This is like chatrooms, but more flexible; a single topical marker can hold multiple separate conversations, and each conversation might be marked with multiple topics.

(we might implement this by making "#wiki" a "virtual person" who "participates in" conversations having to do with wikis).

(The bad thing about that description is that it doesn't at all use the cool "conversational field" metaphor. But it does describe the functionality.)

Hadn't see Luigi for a while I sent him an email about an italian semantic-web I dicovered yesterday http://esw.w3.org/topic/SemWebItaly. How does this relate to http://www.x-arn.org/y/wakka.php?wiki=DistanceFocale he asked back. There is something about coordinates on this page. What I wonder is: Couldn't the conversational fields be descibed as an extension within the conversational space (the conversational universe) in a x/y/z coordinate system (somehow)? Probably pretty stupid. At least a visualisation of that might give us new insights on cloud formation and "weather" in general as hive-mind meterology sees it.

ThomasKalka pointed me to chandler http://www.osafoundation.org/OSAF_Our_Vision.htm. It has a touch of OverHear. Asynchronous P2P was another thing I didn't understand. The coordinates xyz according to him would be foaf, asynchronous p2p (no servers), ontology, geo-coodination. Sorry Thomas for hopelessly copying without undestanding it. Feels to me, I may do so.

Bayle: Yes, I like your new terminology best. And it accurately describes everything. :D

Mattis: Yes, you can draw visualizations of this. It might require abbreviating to make it nice in 2 or 3 D, but I don't see any reason why this couldn't be visualized.

I've been drawing new diagrams for our clearer understanding; I think that when I put the diagrams on the wiki, I'll overwrite the page "OverHear" with them.

Later, we can delete this page- the new terminology is much better.

Define external redirect: SharedWebBrowser ActivityAwareness ConversationFields

EditNearLinks: MeatballWiki WikiMatrix InstantMessaging UserInterface

Languages: