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.
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...) |
|||
| 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- | + | [[Image:Activity-streamsv2.png|center]] |
| − | + | ||
| − | + | ||
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 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. |
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. | ||
Revision as of 01:46, 30 April 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.
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 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.
The Meetup app then overlays on the Meetup site a small picture of Joe beside the listing of Parity-4. Now that's cool.