Interface for the (Public) Graph
Nadia Dresscher-Lambertus, Catalina Iorga, Richard Rogers
The project's aim is to discover and document discrepancies between the outputs of API calls (which can be made on http://graph.facebook.com
if logged in) and the Facebook website for the three types of Facebook pages: people (which is the usual Facebook user account), pages (dedicated to businesses, public figures, celebrities, books, movies, TV series, etc.) and groups (for common interests, causes, etc). Pages are the most permissive, for one need not be logged in to view the material. For groups, there are two types. Legacy groups set to open are visible to the web, and one can join them, without being invited; newer groups set to open are visible only to users logged in. Users can ask to join the group, or may be added by existing group members. One can tell the difference between legacy and new groups in the facebook URL, with the legacy having gid= and the newer ones with sk=group. People are like groups, in that one needs to be logged in to view the material, except for the name and picture.
The research project emerged from using a tool that offers Facebook data through the Facebook API. The piece of software, DiscoverText
, also makes API calls to other online sources such as Twitter. In using the tool, in the Summer of 2011, we found discrepancies between the data collected with DiscoverText
and the data visible or available on the original sources: people, pages and groups. We would like to capture and display the differences. What are the discrepancies in outputs between the API and the screen? What are the implications for research, especially when relying on the API as the main or sole data conduit?
1. The API calls made through applications such as DiscoverText
do not output all the content on a group or page visible on the website because they follow the default display mode of content (Top Posts), thus ignoring posts appearing in the Most Recent view.
2. Permissions (i.e. a group's level of opennnes, a user's privacy settings, etc.) have an impact on the content retrieved by API calls. (The same concern was raised in a blogpost
made by one of the DiscoverText
We return to the project from the Summer School of 2011, Aruba
. We queried Aruba in Facebook, and found differences between the output of the search and that of the API. The search outputs people, pages, places, groups, apps, events, music, web results (served by Bing), posts by friends, public posts and posts in groups. One may filter the results to show just one item type. We would like to compare each category or item type that is outputed in the search returns with those of the API. The first step is to compare the fields. Which are available in the results of search, and which in the API? The second step is to compare the rankings and the third the content of the returns. Both the fields as well as the returns (including both the rankings as well as the contents) should be compared when one is logged in as well as logged out, when one is a member of a group, friend of a person, or otherwise have affiliation. In order to do so, we would like to place the results of the queries and the calls side by side, and employ a comparison tool, such as the one built into the triangulation tool
One has to be logged in to search all categories listed above (people, pages, places, groups, apps, events, music, web results (served by Bing), posts by friends, public posts and posts in groups). There is a search function on the Facebook Directory
, but one can only query people, places and pages. The latter two do not require logging in to be seen. To interact with user profiles (more specifically, with their Walls), even if they are public, one is required to either login or sign up.