Editing Data Sharing With Alice And Bob

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

This document describes a use case wherein Alice offers to enter into a data sharing relationship with Bob.

A cursory knowledge of the concept of a Personal Data Store 2.0 and of the Persona Data Model 2.0 (aka PDM 2.0) is assumed. Although not mentioned explicitly the graph of objects being shared are described in the PDM 2.0 model.

This use case assumes that there is an active client providing a little bit of UI and the ability to kick off sending an email to Bob. But the reality is that 95% of the implementation of this use case is done by the PDS Client 2.0, so a webapp (built on the PDS client library/service) could just as easily have provided the UI instead of an active client with its so-called dashboard UI. Best of all if both kinds of clients existed they would of course interoperate seamlessly.

Introduction

Alice wishes to delegate to her friend Bob authority over the record in Alice's Google Contacts (think gmail) account that is about him, to him. In inviting Bob to do this she simultaneously offers him read-only access to the record about herself. The social protocol is that Alice sends an offer to "stay in sync" to Bob. The offer contains two gifts: (i) a link to the record about Alice so Bob can always have her latest information and (ii) a link to Bob's record so that anytime Bob's information changes Alice gains a copy.

Initial Condition

• Alice has a Higgins-based active client
• Alice has a gmail account wherein at least her friend Bob is listed.
• Bob has no active client installed
  

Implementation #1

Overview

The Google Contacts Context Provider implementation is plugged into Alice's PDS. It exposes Google Contacts in the Persona Data Model but does not simultaneously expose these data as an XDI endpoint.

Open Google Contacts

As shown below, Alice opens a Google Contacts context, providing her gmail username/password credentials. If Alice does not have an entry for herself in Google, then an empty one is created. If Alice does have an entry for herself this is somehow found.

A note about the images in this document. The round cornered boxes are Higgins Contexts. The dotted lines are foaf:knows> link-valued attributes. The solid lines are h:correlation links--which roughly means "this is another facet of me"

Merge into Meta

Initially no h:correlation link exists between Alice's root "MetaMe" entity in the meta context and the root node in the Google Contacts (GC) context. We add the missing h:correlation link and then walk the graph from the root node in the Google Contacts context merging these nodes into new or existing persona nodes under the root node in Alice's meta context.

The result of this generalization process is shown below. As you can see not only is the node representing Alice merged into the meta context but so are all of the other contacts that Alice has, including Bob. For clarity all of Alice's contacts (other than herself and Bob) have been omitted below.

Share Alice's "Alice" and "Bob" nodes with Bob

In the UI of the active client Alice selects the Bob Persona node in her meta context. One of the operations she can perform on a persona is to share it with someone. She chooses to share this Persona with Bob. By Bob here we mean here Bob's email address, an attribute of the Bob node.

For reasons of social protocol Alice simultaneously offers to share her own contact info (node) with Bob. (See the "Stay in Sync?" email below).

After she clicks "Share" on the Bob node in the Meta context the active client (specifically the PAUL component) notices that the Bob Persona node does not live in its own context. Since in Higgins 2.0 the minimum unit for sharing (and access control) is an entire context, the active client must create a new top-level context and move the Bob node into it. Moving the Bob node involves rewriting the link from Alice to Bob so that it points to the moved Bob, which incidently, will now have a new entityid. The Bob node's entityId changes because formerly it was a relative UDI within the meta context and now it must be addressed from the meta context using an absolute UDI.

The new context is an instance of the P-Card Context sub-class namedr-card2. As with all contexts this context from a physical point of view ends up (after synchronization) stored on both the PDS Client and the PDS, however we omit the PDS-located contexts for clarity. After all, from a logical point of view these contexts are the same. This same process is repeated for the Alice node, and results in the creation of the r-card1. Note both of these P-Card Contexts are created as relationship contexts. The result of all this is shown below. The Alice and Bob nodes in r-card1 and r-card2 represent what Alice has asserted about herself and about Bob respectively. These r-card2 and r-card1 contexts are synchronized to the PDS and thereby exposed by the XDI "Attribute Service" endpoint. This data sharing use case leverages the fact that Alice's PDS is now a publisher (over XDI) of these two r-cardX contexts.

Now that the data is in the right places the PDS Client 2.0 needs to add Bob to the access control list for the two new contexts. At this point we only know Bob as his email address, so that must (for now) be how Bob is identified. Since the access control list is maintained by Alice's PDS, Alice's PDS Client must communicate with her PDS to add Bob's identifier to the "allow access" list of r-card1 and r-card2. We add "Bob has full read/write access to r-card2" to the r-card2 ACL. And we add "Bob has read-only access to r-card1" to the r-card1 ACL.

The last step is for the active client to arrange that an email be sent to Bob. The email contains what we call an i-link. This i-link (URI) encodes (a) a link to an active client download site (b) the UDI of the Bob entity on r-card2 (c) the UDI of the Alice entity on r-card1

The text of the email says something like:

Subject: Stay in sync?

I'd like to stay in sync with you. By clicking on the link below please accept my offer to always having my latest contact/profile information. You have the option of Click here to accept my offer. Note: If you don't already have a Higgins active client, clicking here will bring you to a download page where you can get one. I've started using Higgins to stay in sync with co-workers, friends and family. With Higgins everything stays up-to-date because everyone who uses Higgins only has to update their own contact info--and all the changes are automatically reflected it everyone else's address book.

Bob clicks on the i-link

Since Bob's browser doesn't have the Higgins BX installed when he clicks on the i-link it points him to the Higgins download site. Bob downloads and installs an active client. Now Bob has a meta context as shown in Figure 4 below. As mentioned at the outset, Bob is not expected to have a gmail account.

Bob processes the i-link

Higgins active client extracts the UDI of Alice's Bob entity on the r-card she created.

Since the i-link tells Bob about a particular Alice identity, Bob's PDS Client can add a foaf:knows link Bob's MetaMe entity and his friend Alice. Secondly, since the i-link also tells Bob about Alice's representation of Bob (r-card2), Bob's PDS Client can add a h:correlation link from Bob's MetaMe entity to Alice's representation of Bob in Alice's gmail context. The result is shown in figure 5 below:

Implementation #2

Overview

The Google Contacts Context Provider not only exposes the Google contacts to the Persona Data Model but it simultaneously exposes these contacts as an XDI endpoint.

Initial Condition (modified)

We have made another change in assumptions. Our initial condition is that Bob does have a gmail account.

Initial State

As with Implementation #1 in the previous section, we start off in this state. As mentioned the main difference from before is that the Google Contacts context is now a managed r-card context. This means that nodes in it can be directly shared by Alice with others like Bob. In Implementation #1 this was not the case. Alice's PDS Client had to first copy the nodes in the Google Contacts context into two separate r-card1 and r-card2 contexts.

File:Alice-bob-f1.png

Final state: