Sharing & Collaboration

EARLY DRAFT This document is based on a brain-dump and discussion on sharing and collaboration that I had with Andy 3/12. The first goal of the doc is to capture all our ideas on sharing. The second is to serve as a basis for discussion towards a full-blown design document on Chandler sharing.

-- updated 5/7 to include Mitch's idea on collaborating on a set of documents and to list the set of issues we need to resolve for sharing & collaboration

Types of data that can be shared:

• Chandler Information Item. This is basically any Chandler item e.g. email message, event, contact, task, note, etc. any of which should be sharable.
• Views. The query of a view, or a specific collection of items can be shared too.
• Customization of views. This includes not only layout and UI preferences to view customizations but also content customization such as filters or rules.
• Foreign resources. This includes files, URLs and other resources not directly stored it the Chandler repository.
• Code It's little use sharing an item if the client doesn't have the viewer to decode the item. Thus, Viewer Parcels need to be shared. Likewise, it will be useful to share Agents.
• Semantic Dictionaries What is the meaning behind an attribute of a chandler item? Can this meaning be translated to a meaning that the client already understands? Semantic dictionaries allow shared semantics (see section below for further elaboration) between clients
• Reputation The reputation of a sharable item (e.g. code) or person offering to share is crucial to the decision of whether to share (or to accept shared data). Thus, reputation itself is a sharable data type. Question: or is reputation just an attribute?

Sharing Mechanisms

The last section answered what can be shared. This answers how they can be shared or what forms of sharing can take place.

• Browsing In browsing, views of data are accessible by remote party. These views can be read-only or read-write. However, no actual data is incorporated into remote client's repository (except for caching purposes) and data is refetched at each browsing instance.
• Subscription allows incorporation of another client's data into own repository. A publish/subscribe mechanism allows changes to be propagated to subscribers when such changes are made by the publishing repository.
• Synchronization is a two-way subscription process where two remote views of chandler items become identical by incorporating differences in both views. This includes updating the different items themselves as well as the set of items within the two views being synchronized (note: Andy suggests looking into rSync as means to implement synchronization)
• Remote Search allows agents (with the right permissions) to perform remote queries on a repository. The agent can collate local and remote query results as a collection of search results for the user or another agent
• Code Sharing There should be a separate mechanism to share parcels and agents. This mechanism should minimize security issues such as virus propagation.

Collaboration

Besides sharing and browsing, we want people to use Chandler to collaborate better together on a joint project. Chandler collaboration capabilities are built on top of two coordinated capabilities: the sending and receiving messages which form a stream (email, IM's, even blogs), and creating, reviewing, and publishing documents (web pages, word processing). As Mitch puts it, our goals is to combine the best of what wikis and threaded emails can offer. This needs to be further designed.

User Interface issues

There are many user interface issues that sharing introduces. Here are some critical ones:

• We need ways to highlight security and access controls to the client offering to share. We can use our address books as a means to identify individuals and groups who have sharing privileges.
• Each view needs to allow users to specify whether it can be shared and if so, to whom and which groups is the view sharable and in what ways (e.g. read-only). We also need to allow individual items to override the sharing access controls that views specify. (e.g. an item cannot be shared even if it is in a sharable view)
• Views need to facilitate sharing mechanisms e.g. support read-only views, providing UI for publish/subscribe mechanisms

Shared Semantics

For sharing to be truly useful, clients have to understand a common set of semantics for each attribute of a shared item. For example, when subscribing to a contact, the client may need to translate a "business phone" attribute to what this client knows as "work phone". The mapping of different semantics can be as simple as the above one-to-one mapping or a more complicated series of operations.

Chandler should come up with a reference semantics for commonly used attributes within messages, events, contacts, tasks and generic items.

Chandler should also support a framework to support third-party semantics and mappings i.e. Semantic Dictionaries. These Semantics Dictionaries can then be shared together with the corresponding shared items that utilize attributes defined in these semantic dictionaries. This framework should incorporate shared semantics work done by other groups e.g. Dublin Core

In addition, we need to support loosely coupled, free-form ways for people to share and access remote data. One framework would be to allow keywords to describe each Chandler item. A google-like search engine can then aggregate search results based on keywords.

Reputation Manager

We want to allow users to be able to rate the reputation of sharable objects (e.g. agents, contacts, etc.) The reputation manager provides different aggregated views of the reputation of a collection of persons or objects. For example, one view could simply show the arithmetic mean of known reputations of people in an address book. A more interesting view could show the reputation of the same set of people based on reputations and transitive relationships i.e. I trust person X highly, so I trust her ratings on person Y higher than, for example, an anonymous rating.

We may also want to categorize different aspects of a person's reputation. e.g. I rate person X highly for programming advice but mediocre for legal advice.

Reputation is a big topic. We clearly don't have all the answers right now. We spoke to NewsMonster^?'s Kevin Burton who has come up with a reputation manager framework. We will evaluate if his framework fits our needs. [Andy, any update on this? Has Kevin sent us a copy of his paper?]

Marketplace for Offers & Requests

Offers can be made (published) to share items (perhaps for a fee). Requests can also be published to highlight items that a client is looking (perhaps offering a fee).

Chandler can then provide a marketplace mechanism to try to match requests and offers. This will likely need good shared semantics between offers and requests.

Issues to be decided:

• Should we support multiple protocols as a transport for sharing? If so, what are they? (e.g. RAP, Jabber, email, etc.)
• What is our strategy around discovery of other Chandler clients to initiate sharing between clients?
• How do we deal with firewall issues (e.g. how can two Chandler clients between two firewalls communicate)?
• Someone should own and propose a solution to the "shared semantic" issue
• We need to decide if the previous two sections "Reputation Manager" & "Marketplace for Offers and Requests" should make it into Canoga.
• We need ownership and more concrete steps towards designing our "document collaboration" feature

-- ChaoLam - 21 Mar 2003

If the source information is Chandler data then isn't the semantic content of the data already known? If so, any delivery to an outside target would require a parcel to package the data as required by the target.

The parcel would have to query the privacy/security level for each item that will be packaged to see if it meets with the allowed access that the target has negotiated.

Just some thoughts to see if I understand what is being proposed.

-- MikeT - 14 May 2003