Skip to main content
Jump to: navigation, search

Difference between revisions of "Activity Streams In Persona"

(New page: {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} This document describes a use case that requires a few extensions to PDM 2.0 to add the missing Event class and associated...)
 
(Something cool that this model makes possible)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
 
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}  
 
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}  
  
This document describes a use case that requires a few extensions to PDM 2.0 to add the missing Event class and associated attributes. We describe it here to explore how it could be modelled.<br>
+
This document describes a use case that requires a few extensions to PDM 2.0 to add the missing Event class and associated attributes. We describe it here to explore how it could be modelled.<br>  
  
[[Image:Activity-streams.png|center]]  
+
[[Image:Activity-streamsv2.png|center]]  
 
+
''ERRATA: In the above image Party-3 in the Meetup context should be labelled "Parity-4"''
+
  
 
The Facebook context is provided by a web service that reads the Facebook activity streams. Shown above is a single Event that is "from" Joe-3, that is "to" a list of people and is "about" a party, Parity-3. Similarly the Twitter context parses the Twitter stream. In this second context the local name for what is in fact the same party as Party-1 has entityid Party-2. Above these two is a context provided by a Lookup Service. This service's function is to create correlations between events. Shown above, the Lookup Service knows that Party-1 in its namespace is the same as Twitter's Party-2 and Facebook's Party-3. <br>  
 
The Facebook context is provided by a web service that reads the Facebook activity streams. Shown above is a single Event that is "from" Joe-3, that is "to" a list of people and is "about" a party, Parity-3. Similarly the Twitter context parses the Twitter stream. In this second context the local name for what is in fact the same party as Party-1 has entityid Party-2. Above these two is a context provided by a Lookup Service. This service's function is to create correlations between events. Shown above, the Lookup Service knows that Party-1 in its namespace is the same as Twitter's Party-2 and Facebook's Party-3. <br>  
Line 11: Line 9:
 
In the Meta context we see that the user knows a person named Joe-1 and also knows that Joe-1's Facebook handle is Joe-3 and his Twitter handle is Joe-2.  
 
In the Meta context we see that the user knows a person named Joe-1 and also knows that Joe-1's Facebook handle is Joe-3 and his Twitter handle is Joe-2.  
  
=== Something cool that this model makes possible ===
+
=== Something cool that this model makes possible ===
  
Imagine that the user, armed with an active client, has installed a Meetup app-card that performs web augmentation on Meetup.com. The Javascript scrapes the Meetup page and sees an event called "Party-4". It then performs a fairly complex query against the Personal Data Store (the contexts shown above). The intent of the query is to determine which friends of the user are planning to attend Party-4. The query first finds out that Party-1 is the more general identifier for Party-4. Then, starting at the MetaMe node attempts to find all friends of MetaMe (the user) that is attending Parity-1. The search determines that the user's friend Joe-1 is attending Party-1 by looking at the Event in the Facebook stream and seeing that Joe-3 is attending Party-3 which is correlated to Party-1.
+
Imagine that the user, armed with an active client, has installed a Meetup app-card that performs web augmentation on Meetup.com. The Javascript scrapes the Meetup page and sees an event called "Party-4". It then performs a fairly complex query against the Personal Data Store (the contexts shown above). The intent of the query is to determine which friends of the user are planning to attend Party-4. The query first finds out that Party-1 is the more general identifier for Party-4. Then, starting at the MetaMe node attempts to find all friends of MetaMe (the user) that is attending Party-1. The search determines that the user's friend Joe-1 is attending Party-1 by looking at the Event in the Facebook stream and seeing that Joe-3 is attending Party-3 which is correlated to Party-1.  
  
 
The Meetup app then overlays on the Meetup site a small picture of Joe beside the listing of Parity-4. Now that's cool.
 
The Meetup app then overlays on the Meetup site a small picture of Joe beside the listing of Parity-4. Now that's cool.

Latest revision as of 09:39, 12 June 2010

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

This document describes a use case that requires a few extensions to PDM 2.0 to add the missing Event class and associated attributes. We describe it here to explore how it could be modelled.

Activity-streamsv2.png

The Facebook context is provided by a web service that reads the Facebook activity streams. Shown above is a single Event that is "from" Joe-3, that is "to" a list of people and is "about" a party, Parity-3. Similarly the Twitter context parses the Twitter stream. In this second context the local name for what is in fact the same party as Party-1 has entityid Party-2. Above these two is a context provided by a Lookup Service. This service's function is to create correlations between events. Shown above, the Lookup Service knows that Party-1 in its namespace is the same as Twitter's Party-2 and Facebook's Party-3.

In the Meta context we see that the user knows a person named Joe-1 and also knows that Joe-1's Facebook handle is Joe-3 and his Twitter handle is Joe-2.

Something cool that this model makes possible

Imagine that the user, armed with an active client, has installed a Meetup app-card that performs web augmentation on Meetup.com. The Javascript scrapes the Meetup page and sees an event called "Party-4". It then performs a fairly complex query against the Personal Data Store (the contexts shown above). The intent of the query is to determine which friends of the user are planning to attend Party-4. The query first finds out that Party-1 is the more general identifier for Party-4. Then, starting at the MetaMe node attempts to find all friends of MetaMe (the user) that is attending Party-1. The search determines that the user's friend Joe-1 is attending Party-1 by looking at the Event in the Facebook stream and seeing that Joe-3 is attending Party-3 which is correlated to Party-1.

The Meetup app then overlays on the Meetup site a small picture of Joe beside the listing of Parity-4. Now that's cool.

Back to the top