Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Data Sharing With Alice And Bob"

(Open Google Contacts)
Line 3: Line 3:
 
This document describes a use case wherein Alice offers to enter into a data sharing relationship with Bob. Once it is baked it will be folded into the [[R-Card]] paper.  
 
This document describes a use case wherein Alice offers to enter into a data sharing relationship with Bob. Once it is baked it will be folded into the [[R-Card]] paper.  
  
A cursory knowledge of the concept of a [[Personal Data Store 2.0]] and of the [[Persona Data Model 2.0]] is assumed.  
+
A cursory knowledge of the concept of a [[Personal Data Store 2.0]] and of the [[Persona Data Model 2.0]] (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.
+
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 ===
+
=== 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.  
 
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.  
Line 13: Line 13:
 
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.  
 
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 ===
+
=== Initial Condition ===
  
 
Alice has a Higgins-based active client and a gmail account wherein at least her friend Bob is listed. Bob has not got an active client installed.  
 
Alice has a Higgins-based active client and a gmail account wherein at least her friend Bob is listed. Bob has not got an active client installed.  
Line 20: Line 20:
  
 
As shown in figure 1 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<ref>I don't know enough about Google Contacts to know if this can be done automatically or if the active client's UI (the so-called dashboard) must display a list of Alice's contacts and ask her to select the one that is her. We could allow her to specify multiple entries and tag them as personas too in the future.</ref>  
 
As shown in figure 1 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<ref>I don't know enough about Google Contacts to know if this can be done automatically or if the active client's UI (the so-called dashboard) must display a list of Alice's contacts and ask her to select the one that is her. We could allow her to specify multiple entries and tag them as personas too in the future.</ref>  
<blockquote>
+
<blockquote>[[Image:R-card data sharing 1.png|center]] A note about the images in this document. The round cornered boxes are Higgins Contexts. The dotted lines are <code>foaf:knows&gt;</code> attributes. The solid lines are <code>h:correlation</code> links--which roughly means "this is another facet of me" </blockquote>  
[[Image:R-card data sharing 1.png|center]]  
+
=== Merge into Meta ===
 
+
A note about the images in this document. The round cornered boxes are Higgins Contexts. The dotted lines are <code>foaf:knows&gt;</code> attributes. The solid lines are <code>h:correlation</code> links--which roughly means "this is another facet of me"
+
</blockquote>
+
 
+
=== Merge into Meta ===
+
  
 
Since no <code>h:correlation</code> link exists between Alice's root entity in the meta context and the root node in the Google Contacts (GC) context, then this correlation needs to established.  
 
Since no <code>h:correlation</code> link exists between Alice's root entity in the meta context and the root node in the Google Contacts (GC) context, then this correlation needs to established.  
Line 78: Line 73:
 
[[Image:R-card data sharing 5.png]]  
 
[[Image:R-card data sharing 5.png]]  
  
=== References ===
+
=== References ===
  
 
<references />
 
<references />

Revision as of 10:59, 9 April 2010

{{#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. Once it is baked it will be folded into the R-Card paper.

A cursory knowledge of the concept of a Personal Data Store 2.0 and of the Persona Data Model 2.0 (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 and a gmail account wherein at least her friend Bob is listed. Bob has not got an active client installed.

Open Google Contacts

As shown in figure 1 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[1]

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

Merge into Meta

Since no h:correlation link exists between Alice's root entity in the meta context and the root node in the Google Contacts (GC) context, then this correlation needs to established.

This involves creating the h:correlation link as well as walking the entire graph from the root in the GC context down and merging it into either a new or an existing persona branch under the root (aka MetaMe) node in Alice's meta context.

The result of this generalization process is shown in figure 2 below. As you can see not only is the node representing Alice merged into the meta context but all of the other contacts that Alice has (including Bob) are merged in too. The dotted lines are foaf:knows links.

For clarity all of Alice's contacts (other than herself and Bob) have been omitted for simplicity in Figure 2 below.

R-card data sharing 2.png

Share Alice's (Alice and Bob) 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 node with Bob. And by Bob we mean here Bob's email address (which is an attribute of the Bob entity).

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

After she clicks "Share" on the Bob node in the Meta context the PAUL component notices that the Bob Persona node is not in its own context, and since the minimum unit for sharing (and access control) is an entire context, it must create a new 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 will now have a new entityid (why? because 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 created is a personal r-card2 (note: we've recently changed all i-cards to be context sub-classes). To create this there must be some communication with the PDS so that we end up with a new context in the PDS Client as well as on the PDS itself.

This same process is repeated for the Alice node, and results in r-card1 in both the PDS Client and the PDS.

The result of all this is shown in Figure 3 here:

R-card data sharing 3.png

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 new contexts. Now at this point we only know Bob as his email address, so that must (for now) be his identifier.

The access control list is maintained by the PDS, so Alice's PDS Client must communicate with the PDS to add Bob 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.

The 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 just takes him to the Higgins download site. Bob downloads and installs an active client. Now Bob has a meta context as shown in Figure 4 here:

R-card data sharing 4.png

Higgins active client extracts the UDI of Alice's Bob entity on the r-card she created. The PDS client resolves this UDI and thus creates the r-card1 context in Bob's PDS Client as fetched from the PDS. The same is done for the "Alice" UDI. The result is shown in Figure 5.

R-card data sharing 5.png

References

  1. I don't know enough about Google Contacts to know if this can be done automatically or if the active client's UI (the so-called dashboard) must display a list of Alice's contacts and ask her to select the one that is her. We could allow her to specify multiple entries and tag them as personas too in the future.

Back to the top