Background
Handling location in activity streams is an important way to define the context of the actor — i.e. where an activity took place.
Both the actor and the object of an activity may feature locative information; how location is handled in such circumstances is up to the consuming software.
Purpose
Location is relevant as a filter in real-time feeds (consider the many Twitter-based maps), or as a mechanism to learn more about the context of the actor or activity. Equally relevant is the location of an object, or more precisely, where an object is located, especially if it is different from the author. While it may not be possible to express why the actor and the object are not co-located, it's worth noting that they can in fact be located separately, for example if an actor writes a review about a restaurant they visited last week.
In previous standards efforts (specifically GeoRSS), location was presumed to be a property of the entire entry. In Activity Streams, location can be a property of either the entire entry OR of the actor and object OR one of the actor or objects. In the case where multiple objects are referenced as part of an activity (as in a feed contained with a feed), each object element may have a unique location, as in the case of a photographer uploading a set of images after a long trip to several different destinations.
Location can be used to place activities on a map in real-time, or can be used to enhance historical search, helping a searcher filter by the location of an actor or activity at a certain time and place.
Use Cases
- Users may want to identify a location by:
-
- Lat/long
- URI
- Street address
- Metro
- Neighborhood
- providing the location of the actor "right now" — that is, when the feed is rendered for the viewer, grab the most current location record for the actor
- Providing the user's home city. Some sites call this hometown but its the current location. This is part of the profile info users fill into sites like MySpace, Twitter, Gowalla etc . Useful when looking at public information and users outside the reader's social graph
- providing the location of the actor when the activity took place
- providing the location where the activity took place (i.e. "at the wedding in Vermont")
- providing the location of the object of an activity (i.e. the address of a restaurant that was reviewed)
- ...others?
Adding Location to ActivityStreams
Location can be represented as a child of <entry>, <atom:author>, and/or <activity:object>
Location should be represented by <poco:address>, <geo:point> or both.
These are all optional.
<feed>
<entry>
<author>
<poco:address> ...
<geo:point> ...
</author>
<activity:object>
<activity:object-type>...place</activity:object-type>
<poco:address> ...
<geo:point> ...
</activity:object>
<poco:address> ...
<geo:point> ...
</entry>
</feed>
Implementors should put location data:
- Home location of the author within the <atom:author> location
- Immediate physical location of the author at the time of the activity in the <entry> location
- Location of a place (or other object) in the <activity:object> location
Examples
Twitter (optionally) embeds geolocation information in a tweet based on the location of the user at the time the tweet was created and the same for MySpace on their Real time stream
- Events (ex: evite, MySpace, Facebook, Google Calendar, etc.) nearly always have a location associated with the event
- Venues (ex: Yelp, Urban Spoon, Qype)
Examples of multiple location use cases could be:
- Filtering for reviews of a place written by people from another location (ex: Kevin Marks wants to read reviews of pubs in the SoMa area written by people who are from London)
- Filtering check-ins that were made off-site (ex: Rob wants to see if people check-in to Microsoft building 88 who aren't actually at building 88)