UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Unifying the social landscape with OpenMe Tsao, Vincent 2012

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2012_spring_tsao_vincent.pdf [ 4.27MB ]
Metadata
JSON: 24-1.0072662.json
JSON-LD: 24-1.0072662-ld.json
RDF/XML (Pretty): 24-1.0072662-rdf.xml
RDF/JSON: 24-1.0072662-rdf.json
Turtle: 24-1.0072662-turtle.txt
N-Triples: 24-1.0072662-rdf-ntriples.txt
Original Record: 24-1.0072662-source.json
Full Text
24-1.0072662-fulltext.txt
Citation
24-1.0072662.ris

Full Text

    Unifying the Social Landscape with OpenMe by Vincent Tsao B.Sc., The University of British Columbia, 2009 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in The Faculty of Graduate Studies (Electrical and Computer Engineering) THE UNIVERSITY OF BRITISH COLUMBIA (Vancouver) April, 2012 © Vincent Tsao 2012   ii Abstract With the rapid rise of the popularity of online social networks (OSNs) in recent years, we have seen tremendous growth in the number of available OSNs.  With newer OSNs attempting to draw users in by focussing on specific services or themes, it is becoming clearer that OSNs do not compete on the quality of their technology but rather the number of active users.  This leads to vendor lock-in, which creates problems for users managing multiple OSNs or wanting to switch OSNs.  Third party applications are often written to alleviate these problems but often find it difficult to deal with the differences between OSNs.  These problems are made worse as we argue that a user will inevitably switch between many OSNs in his or her lifetime due to OSNs being incredibly fashionable things whose lifespan is dependent on social trends.  Thus, these applications often only support a limited number of OSNs.  This thesis examines how it is possible to help developers write apps that run against multiple OSNs.  It describes the need for and presents a novel set of abstractions for apps to use to interface with OSNs.  These abstractions are highly expressive, future proof, and removes the need for an app to know which OSNs it is running against. Two evaluations were done to determine the strength of these abstractions.  The first evaluation analyzed the expressiveness of the abstractions while the latter analyzed the feasibility of the abstractions.  The contributions of this thesis are a first step to better understanding how OSNs can be described at a high level.   iii Table of Contents Abstract ................................................................................................... ii	
   Table of Contents ................................................................................ iii	
   List of Tables ........................................................................................ vi	
   List of Figures ....................................................................................... ix	
   Acknowledgements ............................................................................... xi	
   1  Introduction ....................................................................................... 1	
   1.1	
   OSN Application Challenges .......................................................... 2	
   1.2	
   OSNs are Fashion .......................................................................... 3	
   1.3	
   Research Problem .......................................................................... 3	
   1.4	
   Research Contributions .................................................................. 4	
   1.5	
   Thesis Structure ............................................................................. 5	
   2  Related Work .................................................................................... 6	
   2.1	
   Definitions of Social Networks ....................................................... 6	
   2.2	
   Unified Social Network Services ..................................................... 7	
   2.3	
   OpenSocial ..................................................................................... 8	
   2.4	
   Semantic Web ................................................................................ 9	
   2.5	
   Summary ...................................................................................... 10	
   3  OpenMe ............................................................................................. 12	
   3.1	
   OpenMe Abstraction Structure .................................................... 12	
   3.1.1	
   OpenMe Graph, Relationships, and Objects ......................... 13	
   3.1.2	
   Using Relationships ............................................................... 17	
   3.1.2.1	
   General Relationship Usage ............................................ 18	
   3.1.2.2	
   Creating a Relationship .................................................. 18	
   iv 3.1.2.3	
   Reading a Relationship ................................................... 19	
   3.1.2.4	
   Updating a Relationship ................................................. 20	
   3.1.2.5	
   Deleting a Relationship ................................................... 21	
   3.2	
   OpenMe Relationships and Types ................................................ 22	
   3.2.1	
   Roles ...................................................................................... 23	
   3.2.2	
   Content .................................................................................. 25	
   3.2.3	
   OSN ....................................................................................... 27	
   3.2.4	
   Location ................................................................................. 28	
   3.2.5	
   Desires and Deeds .................................................................. 29	
   3.2.6	
   Permissions and Collaboration .............................................. 30	
   3.3	
   Summary ...................................................................................... 31	
   4  Evaluation ........................................................................................ 32	
   4.1	
   Expressiveness .............................................................................. 32	
   4.1.1	
   Methodology .......................................................................... 34	
   4.1.2	
   OpenMe Relationships to OSN Endpoints Mapping ............. 34	
   4.1.2.1	
   Roles ............................................................................... 35	
   4.1.2.2	
   Content ........................................................................... 38	
   4.1.2.3	
   Location .......................................................................... 44	
   4.1.2.4	
   Desires and Deeds ........................................................... 45	
   4.1.3	
   Discussion and Results .......................................................... 47	
   4.1.3.1	
   OSN Endpoints of Note .................................................. 47	
   4.1.3.2	
   Unsupported OSN Functionality .................................... 48	
   4.1.3.3	
   Coverage ......................................................................... 48	
   4.2	
   Feasibility .................................................................................... 49	
   4.2.1	
   Methodology .......................................................................... 50	
   4.2.2	
   Implementation ..................................................................... 52	
   4.2.2.1	
   OpenMe Architecture ...................................................... 52	
   4.2.2.2	
   Merging OpenMe OSN Objects ....................................... 55	
   4.2.2.3	
   Instapen Architecture and Interface ................................ 59	
   v 4.2.3	
   Discussion and Results .......................................................... 62	
   4.3	
   Summary ...................................................................................... 62	
   5  Conclusion ........................................................................................ 64	
   5.1	
   Contribution Summary ................................................................ 64	
   5.1.1	
   Abstract Existing OSNs ........................................................ 65	
   5.1.2	
   Black Box Behaviour ............................................................. 65	
   5.1.3	
   Future Proof .......................................................................... 65	
   5.2	
   Future Work ................................................................................ 66	
   5.2.1	
   Evolving OpenMe .................................................................. 66	
   5.2.1.1	
   Evaluation ....................................................................... 66	
   5.2.1.2	
   OpenMe OAuth Proxy .................................................... 67	
   5.2.2	
   Improving OpenMe ................................................................ 67	
   5.2.2.1	
   Support more OSNs ........................................................ 67	
   5.2.2.2	
   Improve Merging Algorithms .......................................... 67	
   5.3	
   Concluding Remarks .................................................................... 68	
   Bibliography ......................................................................................... 69  Appendices A  OpenMe OSN Object Abstractions ........................................... 76	
   B  Expressiveness Evaluation .......................................................... 78	
   B.1	
   Roles ............................................................................................ 78	
   B.2	
   Content ....................................................................................... 81	
   B.3	
   OSN ............................................................................................. 88	
   B.4	
   Location ....................................................................................... 89	
   B.5	
   Desires and Deeds ....................................................................... 90	
   B.6	
   Unsupported OSN Functionality ................................................. 91	
     vi List of Tables Table 1.  OSN functionality not supported in this version of OpenMe. ... 33	
   Table 2.  Legend of abbreviations used in the following tables in the interest of space. .................................................................................. 35	
   Table 3.  Select OSN specific functionality that the OpenMe is- mutual-with relationship can abstract. ........................................... 36	
   Table 4.  Select OSN specific functionality that the OpenMe follows relationship can abstract. ..................................................................... 36	
   Table 5.  Select OSN specific functionality that the OpenMe knows relationship can abstract. ..................................................................... 37	
   Table 6.  Select OSN specific functionality that the OpenMe is-family relationship can abstract. ..................................................................... 38	
   Table 7.  Select OSN specific functionality that the OpenMe is-part- of relationship can abstract. ............................................................... 38	
   Table 8.  Select OSN specific functionality that the OpenMe posted- photo-on relationship can abstract. .................................................. 39	
   Table 9.  Select OSN specific functionality that the OpenMe likes relationship can abstract. ..................................................................... 40	
   Table 10.  Select OSN specific functionality that the OpenMe shared- on relationship can abstract. ............................................................... 41	
   Table 11.  Select OSN specific functionality that the OpenMe is-in- newsfeed-of relationship can abstract. ........................................... 41	
   Table 12.  Select OSN specific functionality that the OpenMe is- tagged-in relationship can abstract. ................................................ 42	
   Table 13.  Select OSN specific functionality that OpenMe created relationship can abstract. ..................................................................... 43	
   Table 14.  Select OSN specific functionality that OpenMe added-to relationship can abstract. ..................................................................... 43	
   Table 15.  Select OSN specific functionality that the OpenMe is- located-at relationship can abstract. ............................................. 44	
   vii Table 16.  Select OSN specific functionality that the OpenMe was- located-at relationship can abstract. ............................................. 45	
   Table 17.  Select OSN specific functionality that the OpenMe is-near relationship can abstract. ..................................................................... 45	
   Table 18.  Select OSN specific functionality that the OpenMe wants- to-be-mutual relationship can abstract. ......................................... 46	
   Table 19.  Select OSN specific functionality that the OpenMe wants- to-do relationship can abstract. ........................................................ 46	
   Table 20.  Select OSN specific functionality that the OpenMe wants- to-visit relationship can abstract. .................................................. 46	
   Table 21.  Select OSN specific functionality that the OpenMe has-done relationship can abstract. ..................................................................... 46	
   Table 22.  Select OSN specific functionality that the OpenMe wants- to-attend relationship can abstract. ................................................ 46	
   Table 23.  OSN endpoints of note.  These endpoints may be supported in OpenMe, but not using relationships, or contain caveats. ................... 48	
   Table 24.  Percentage of OSN specific functionality that is covered by OpenMe.  These endpoint counts do not include endpoints of functionality we have explicitly stated to not support in this version of OpenMe. .............................................................................................. 49	
   Table 25.  The OpenMe relationships that were implemented in our feasibility evaluation. ........................................................................... 51	
   Table 26.  An example of an OpenMe to provider object mapping in the OpenMe database. ............................................................................... 56	
   Table 27:  OpenMe abstract object mappings to Foursquare, Facebook, and Twitter. ......................................................................................... 77	
   Table 28.  OSN specific functionality that OpenMe role relationships can abstract. ............................................................................................... 78	
   Table 29.  OSN specific functionality that OpenMe content relationships can abstract. ........................................................................................ 81	
   Table 30.  OSN specific functionality that OpenMe OSN abstractions relationships can abstract. ................................................................... 88	
   viii Table 31.  OSN specific functionality that OpenMe location relationships can abstract. ........................................................................................ 89	
   Table 32.  OSN specific functionality that OpenMe desires and deeds relationships can abstract. ................................................................... 90	
   Table 33.  OSN specific functionality that is not supported in this iteration of OpenMe. ............................................................................ 91	
     ix List of Figures Figure 1.  OpenMe is an abstraction layer that sits between applications and OSNs so that the application does not interface with OSNs directly allowing the app to run against any combination of OSNs. ... 12	
   Figure 2.  OpenMe provides a high level OSN graph that unifies an arbitrary number of OSNs, which can (1) given an OSN’s graph, construct a graph in OpenMe that means the same thing, and (2) given an OpenMe graph, any OSN can interpret it and construct what it means within the context of that specific OSN. .................................. 13	
   Figure 3.  (a) OSN graphs are not explicit, but their meaning  can be interpreted from actions that occur within the OSN that created the graph.  (b) OpenMe embeds actions that create graphs into the connections between data objects and calls them relationships. .......... 14	
   Figure 4.  The anatomy of an OpenMe relationship. Each relationship has a source object, a target object, and a name that describes the relationship.  Some relationships may contain a relationship object and additional relationship data. ................................................................ 15	
   Figure 5.  Every object in OpenMe has an implicit has relationship (Section 3.2.3) to the OSN object, which is a singleton. A number of arbitrary objects are shown in this figure. All other relationships between the objects are not shown. ..................................................... 15	
   Figure 6.  Detailed example of how an instance of an OpenMe graph and three OSN specific graphs map to each other.  Selected data is shown on each object. ..................................................................................... 17	
   Figure 7.  Legend that describes the symbols used in the relationship hierarchy diagrams shown in the following sections. ........................... 22	
   Figure 8.  Role relationships and their hierarchal structure. .................... 23	
   Figure 9.  Content relationships and their hierarchal structure. .............. 25	
   Figure 10.  OSN relationships and their hierarchal structure. ................. 27	
   Figure 11.  Location relationships and their hierarchal structure. ........... 28	
   x Figure 12.  Desires and deeds relationships and their hierarchal structure.  ............................................................................................................. 29	
   Figure 13.  Permissions and collaboration relationships and their hierarchal structure. ............................................................................. 30	
   Figure 14:  The OpenMe platform is a piece of middleware that sits between OSNs and apps using it.  It provides a number of adapters to map each OSN’s functionalities to the OpenMe relationships. ............ 50	
   Figure 15.  Diagram showing the different components working with OpenMe. .............................................................................................. 52	
   Figure 16.  A UML diagram depicting the class and package structure of the OpenMe backend. .......................................................................... 53	
   Figure 17.  For each object in each of the OSN lists, we determine if it needs to be merged with any objects in the other OSN lists.  In this example we have determined that objects 2-3 and 3-3 need to be merged and are added to the list of objects that need to be merged. Merging is performed at the end of our algorithm in the merge step. . 57	
   Figure 18.  Comparing all objects in an OSN against all other objects in different OSNs to determine if they can be considered the same object. In this example, objects 1-1 and 2-2 have been determined equal and thus one of them is added to the list of objects that need to be merged.  ............................................................................................................. 58	
   Figure 19.  The final merge step of our algorithm where all objects are merged.  In this example we see objects 2-3 and 3-2 being merged with 1-1 and object 2-2 being merged with 3-1 as we keep track of which objects each object in the to merge list are to be merged with. .......... 59	
   Figure 20.  Diagram showing that Instapen communicates with. ............ 60	
   Figure 21.  Standard workflow for using the Instapen application. .......... 61   xi Acknowledgements I would like to thank Dr. Sidney Fels and Dr. Rodger Lea for supervision, guidance, and looking after me all these years.  Special thanks to Dr. Mike Blackstock as well who first brought me into the MAGIC Lab and offered constant support and help over the years.  Thank you mom, dad, and brother for your support, love, and believing in me.  And last but not least, thank you to all MAGIC and HCT friends and colleagues.   1 Chapter 1 Introduction We have seen a significant rise in the popularity of online social networking sites (OSNs) over the past few years [6].  They are becoming increasingly varied as many new OSNs focus on specific themes, principles, audiences, or services in order to obtain users that may find similar aspects lacking in generic “all-in-one” OSNs [18, 40, 63].  For example, Formspring1 is an OSN that focuses on users asking other users questions.  Instagram2 is an OSN that provides services for applying artistic filters to photos. Google+3 promotes its uniqueness by often mentioning its concept of circles.  Because of this, it is common for a user to be a part of multiple OSNs to keep in touch with his or her social circles [18] as the union of OSNs used by a user’s social circles is most likely greater than one [60]. This however raises problems.  As OSNs do not interoperate well with one another [21, 22, 50, 62], difficulties arise when users want to read or share content between multiple OSNs.  Often times a user would want to post the same content to a number of different OSNs, or port data from one OSN to another [25, 32, 57].  OSN apps or games can also often only be played on specific OSNs [12, 41], and thus only include a subset of a user’s social circles.  Websites or applications wanting to integrate with multiple OSNs to provide their users with the best social experience often only do so with the most popular ones [11, 27].  Mashing up data from different OSNs also becomes difficult for users [7, 30, 39, 44].  OSNs lack interest in solving these problems because it is well known that they do  1 http://www.formspring.me 2 http://instagr.am 3 http://plus.google.com 2 not compete on the quality of their services but rather the number of users they have [10, 67].  This is often referred to as vendor lock-in [5, 51]. Typically these problems are solved by third party applications written to automate tasks such as sharing content across OSNs, porting data, or aggregating information.  For example, Nadamoto, et al., describe how Wikipedia4 can be used to help understand the “gist” of a large discussion occurring on an OSN without having to read every post [52]. Similarly, there are multiple other academic works that suggest how multiple OSNs and services can be used together to solve a problem [8, 26, 48].  These applications all need to be able to run against and support multiple OSNs, but this can be difficult due to the differences that exist between them. 1.1 OSN Application Challenges There are numerous problems that can arise when writing applications that run against multiple OSNs [37].  The most prominent of which is dealing with the meaning of concepts or features across different OSNs [38].  For example, apps may want to message other users, tag other users, or befriend other users on behalf of a user.  If this app runs against multiple OSNs, then it needs to deal with how these features are represented in each of the OSNs it is supporting and make them work together at a higher level.  Additionally, the application also needs to be able to compensate for features existent in one OSN but not another. Sometimes there is a similar feature or method that allows one OSN to pseudo-support that feature.  For example before Twitter formally supported photos, photos in tweets were often “attached” through links. There are other lesser problems that arise with writing apps against multiple OSNs.  Differences in authentication protocols (e.g.:  OAuth 1.0a and OAuth 2), security mechanisms, and API structures can be tedious for developers to keep track of and implement [23].  These are engineering  4 http://en.wikipedia.org 3 problems and thus less difficult to solve than the abstraction problem, but contribute to the greater problem of writing applications against multiple OSNs. 1.2 OSNs are Fashion The difficulty of developing applications that run against multiple OSNs is made worse by the fact that OSNs are fashionable things [31, 45, 53]. We argue that a user will use sets of different OSNs throughout his or her lifetime depending on which ones are the current trend [19, 20].  OSNs are akin to fashion because their success is based on their number of users and thus very dependent on human behavioural patterns and trends [61, 63].  The consequence of this, for applications that run against multiple OSNs, is that every time a new OSN becomes popular, an application needs to be updated to support the new OSN or risk becoming obsolete. This task usually involves figuring out the semantics of the new OSN and how it fits into how the application has previously abstracted the semantics of the current OSNs it supports.  If the application was written to work at a low level with specific OSNs, it may be very tedious or difficult to incorporate the new OSN. 1.3 Research Problem In this thesis, we investigate how to make it easier for developers to write applications that run against multiple OSNs.  As the world of OSNs is a constantly changing one, it can often times be very inefficient for these applications to communicate with OSNs at a low level.  This is especially true if these applications want to do the same thing on the different OSNs they support.  Our research problem is to examine the similarities between OSNs in terms of their features and concepts to see if these can be abstracted into a higher-level language for applications to interface with OSNs. 4 Our main research goal is to devise a set of such abstractions.  These abstractions would then be able to map down to each OSN they support and ideally any OSN that exists.  For example, if we examine an arbitrary abstraction “A”, and we asked what “A” meant in Facebook, we would be able to determine that.  Similarly, we would also know what “A” means in Twitter.  Furthermore, such OSN abstractions should also be able to adequately adapt to future OSNs, not just existing ones.  Existing abstractions should have meaning in new OSNs that have not been seen before.  If new OSNs contain concepts or features that have not been abstracted, our abstractions should be extendable without breaking existing abstractions. The need to create such a core set of OSN abstractions is incredibly important, especially if OSNs are becoming more and more diverse and constantly changing.  Appropriate applications should be able to use these OSN abstractions to interface with OSNs instead of using the OSN specific APIs to achieve the same result.  This is the main research problem and goal of this thesis. 1.4 Research Contributions Our primary research contribution is that we have developed a novel set of OSN abstractions that apps can use to interface with OSNs.  Our abstractions are built from the concept of social network graphs and focus on abstracting relationships between objects in OSNs rather than the objects themselves.  Having taken this approach, our abstractions are highly expressive and are able to represent the majority of functionality in many existing OSNs.  These relationships are also structured in such a way so that they can behave like a black box.  Applications are not required to know which OSNs they are using these abstractions to interface with, making it adaptable to a wide variety of OSNs. Furthermore, this structure allows for relationships to represent functionality that may arise in future OSNs without breaking support for 5 existing ones.  We have also provided a formal evaluation of our OSN abstractions that focuses on their expressiveness and feasibility.  To summarize, the research contributions of this thesis are as follows: • We have specified requirements for what an OSN abstraction layer needs in order to be successful • We have developed a set of OSN abstractions that meet our requirements • We have performed formal evaluation on the expressiveness of our abstractions • A proof of concept service was implemented to realize the abstractions and test feasibility as well as allow a comprehensive analysis to be done on our entire work 1.5 Thesis Structure The remainder of this thesis is structured as follows.  Chapter 2 presents work related to helping app developers create apps that run against multiple OSNs and discusses the significance of each.  Chapter 3 presents our solution called OpenMe, a set of high-level OSN abstractions. Evaluation methods and results are discussed in Chapter 4.  Finally, Chapter 5 concludes and presents work to be done in the future on the OpenMe abstractions.   6 Chapter 2 Related Work In this chapter we present related work that has been done in the area of social network abstraction.  Much of these works have goals similar to our research problem in unifying social networks and increasing social network interoperability.  However, to the best of our knowledge there has been no work done on abstracting OSNs that meet the same requirements we have defined.  This chapter organizes the related work into categories, where each category represents a different approach to abstracting OSNs and solving problems caused by the differences between OSNs 2.1 Definitions of Social Networks Some work has been done on describing what an online application needs in order to be considered an OSN [6, 43].  These works state that an OSN must (1) allow users to construct profiles, (2) articulate other users with whom they share a connection, (3) traverse their own connections as well as connections made by other users, and (4) post content.  These high- level requirements can theoretically be applied to any existing OSN. However, these are not language elements that apps can use to interface with OSNs.  For example, it does not answer the question of how one abstracts the different methods for a user to articulate other users with who they share a connection with across OSNs.  These requirements are also a bare minimum of what an OSN must have, acting as a lowest common denominator.  Thus these definitions can act as a motivator for a set of OSN abstractions, but are not developed enough for what we require. 7 2.2 Unified Social Network Services Unified social network services exist to help third party applications develop against multiple OSNs more easily.  A unified social network service often provides a single point of entry to communicate with multiple OSNs.  Although the goal of unified services is similar to ours, they do not necessarily act as a black box when interfacing with multiple OSNs, nor do they necessarily provide any form of abstraction. Unified services became prevalent when the use of instant messenger (IM) services became widespread [51].  Trillian5, Pidgin6, and Meebo7 were popular (and still used today) unified IM services [2] that allowed users to communicate with friends from multiple IM protocols using a single IM interface.  Similarly with the rise of modern smart phones platforms, there have been many unified mobile development frameworks [1, 35] offering abstract SDKs to help developers build applications for multiple mobile platforms. In the area of OSNs, unified services are generally seen in industry as commercial services.  Two common examples are Gigya8 and Windsoc9. Gigya provides a unified OAuth proxy for developers to enable connecting websites to OSNs.  They are mostly focussed on providing social identity and analytics to third party developers and have a basic unified API. Gigya’s unified API is an aggregation of the common functionality found in a number of popular OSNs.  The API methods are not categorized in any way and provide no abstraction of OSN functionality as each method only works for specific OSN providers. Windsoc provides a unified OSN API that acts mostly as a black box as most of its API methods work against any of the OSNs it supports without needing to know which OSNs are being run against.  Windsoc  5 http://www.trillian.im 6 http://www.pidgin.im 7 https://www.meebo.com 8 http://www.gigya.com 9 http://www.windsoc.co 8 also provides abstractions for OSN news feed functionality based on the ActivityStreams10 standard.  Their API methods are categorized, but it is unclear how this is done.  For example, comment retrieval functionality is in a category on its own, but could also be categorized under activities since a comment is an activity that can appear on a user’s news feed. Some categories also lack abstraction such as the category titled “Contacts/Followers/Following”.  Lastly, there is no indication of how complete their API is in terms of expressiveness for the OSNs they support.  Even many of the existing functionality supported by Windsoc is read-only. 2.3 OpenSocial Another approach to make it easier for developers to write applications that run against multiple OSNs is to encourage OSNs to adhere to standards in terms of what functionality they provide and how it is exposed to third parties apps.  One major example of this is the OpenSocial11 [59] project initiated by Google in 2007.  The OpenSocial initiative encourages existing OSNs and new OSNs to adhere to a standard so that third party applications can interoperate between all OpenSocial OSNs easily. Although there has been some adoption of OpenSocial [28], most popular OSNs lack interest in adhering to the OpenSocial standard because, as previously mentioned, OSNs compete on how many active users they have and not the quality of their technologies.  Thus, due to this business model, OpenSocial has not seen widespread adoption. However, regardless of adoption, it is important to examine how the OpenSocial standard generalizes OSNs.  The OpenSocial 1.1 API specification organizes API endpoints into categories called services.  Each service represents a concept such as “people”, “groups”, “activities”,  10 http://activitystrea.ms 11 OpenSocial - http://www.opensocial.org 9 media”, and so forth, suggesting that these are common functionalities found in OSNs.  These services are not actually higher-level abstractions as many OSNs use the same terminology to mean similar things.  But in some cases there are naming conflicts.  For example, the term “group” does not always mean the same thing across OSNs.  In Facebook it represents an internal forum whereas in OpenSocial it represents a circle of friends.  In this sense OpenSocial provides what it believes are the most important or common functionalities found across OSNs.  This means that the decisions to include and not include certain functionalities are subjective. OpenSocial will however by design create a black box for apps, as an app will interface with all OSNs that adhere to OpenSocial standards in the same way.  Overall the goals of OpenSocial are the same as ours and as a standard it can work well, but it does meet the requirements we seek. 2.4 Semantic Web Another standards based approach for unifying aspects of social networks is semantic web.  Semantic web is the idea of making information that exists on the Internet machine readable [9, 46].  This allows for things such as social network analysis, aggregation of data, or identity mapping. Semantic web is achieved through the use of standards commonly depicting how a social network should markup or feed content in a particular category of data.  These categories can be things like “friends and relationships”, “activities”, “location”, and so forth.  Semantic web is composed of a number of these various formats or standards, some even being referred to as microformats [14, 36]. However, being standard based, semantic web formats are at the mercy of OSN providers implementing them.  Semantic web standards are also very much meant to retrieve data and not write data to OSNs.  This means that data can be mapped from OSNs to a semantic web format, but not necessary mapped back to what it means in a specific OSN.  It is 10 also not meant to replace OSN APIs for information access as its primary use cases is to be read by a web crawler.  But when used to access OSN data it can mask the OSNs and create a black box similar to the effect of OpenSocial. Semantic web standards generalize and abstract concepts in the category they are created for.  Three notable semantic web specifications include Friend-of-a-Friend (FOAF)12 [17, 22], Activity Streams13, and Semantically-Interlinked Online Communities (SIOC)14 [4].  FOAF focuses on relationships between users while Activity Streams and SIOC focus on content feeds and discussions.  Usually two or more semantic web standards are used together to achieve a task.  But each standard may be structured in a different manner, making the usage of semantic web standards fragmented [56].  This, coupled with the read-only nature of feeds, does not make it ideal for the more general use cases we seek of apps interfacing with multiple OSNs. 2.5 Summary In this chapter we have reviewed different categories of related work that aim to solve the problems that arise from differences between OSNs.  We have seen that OSNs can be difficult to abstract and generalize and that there is indeed much motivation and effort in this field. However, it has become apparent through this review that none of these existing works solve the problem of helping apps interface with multiple OSNs with the requirements we have defined.  While Gigya and Windsoc provide unified APIs, they do not behave as a black box, nor attempt to cover all OSN functionality.  On the other hand, OpenSocial and Semantic Web present a standards based approach, but require the cooperation of OSN providers and thus do not work with many existing  12 Friend of a Friend Project - http://www.foaf-project.org 13 Activity Streams - http://activitystrea.ms 14 Semantically-Interlinked Online Communities - http://sioc-project.org 11 OSNs.  The findings in this chapter strengthen our goals of creating a set of OSN abstractions that apps can use to interface with OSNs that can be used with existing OSNs, future OSNs, and behave like a black box when desired.   12 Chapter 3 OpenMe It has become clear from examining related work that no existing OSN abstractions satisfy our research problem and goals.  We want a set of OSN abstractions that are capable of supporting existing OSNs, be able to easily support future OSNs, and hide all OSN specific details.  In this chapter we present a set of abstractions called OpenMe that achieves those goals. 3.1 OpenMe Abstraction Structure  Figure 1.  OpenMe is an abstraction layer that sits between applications and OSNs so that the application does not interface with OSNs directly allowing the app to run against any combination of OSNs. OpenMe is a set of OSN abstractions that sits between third party applications and the OSNs they run against (Figure 1).  OpenMe is based on the idea that OSNs can be represented as graphs where nodes are data objects and edges indicate that one object is connected to another object [29, 54].  The concept of OpenMe is to provide a high level OSN graph that unifies an arbitrary number of OSNs using an abstraction language, which can (1) given an OSN’s graph, construct a graph in OpenMe that 13 means the same thing, and (2) given an OpenMe graph, any OSN can interpret it and construct what it means within the context of that specific OSN (Figure 2).  Figure 2.  OpenMe provides a high level OSN graph that unifies an arbitrary number of OSNs, which can (1) given an OSN’s graph, construct a graph in OpenMe that means the same thing, and (2) given an OpenMe graph, any OSN can interpret it and construct what it means within the context of that specific OSN. 3.1.1 OpenMe Graph, Relationships, and Objects The OSN specific graphs shown in Figure 2 are usually not explicit, meaning that the OSN does not expose itself as a graph.  These graphs however can be constructed in a fairly straightforward manner given the data in an OSN.  In these OSN graphs the connections between two data objects is often not described, but rather is a result of an action that occurs in the social network (Figure 3).  In the OpenMe abstraction graph we have combined the connection between two data objects with a description of the action that created the connection.  This is a richer representation of an edge in a social network graph and we refer to this as a relationship between two data objects. 14  Figure 3.  (a) OSN graphs are not explicit, but their meaning  can be interpreted from actions that occur within the OSN that created the graph.  (b) OpenMe embeds actions that create graphs into the connections between data objects and calls them relationships. The anatomy of a relationship is shown in Figure 4.  Every relationship has a source object, a target object, and a name to describe the action that the source object has taken or takes on the target object. These objects are OpenMe abstractions of OSN specific objects, but are usually not very high level since OSNs either have very similar objects, thus not requiring high level abstraction, or very different objects, in which case makes it very difficult to abstract.  Instead, we simply allow for a plethora of objects to be used in OpenMe.  A full list of objects that exist in OpenMe and what object(s) they represent in respective OSNs is shown in Appendix A. 15  Figure 4.  The anatomy of an OpenMe relationship. Each relationship has a source object, a target object, and a name that describes the relationship.  Some relationships may contain a relationship object and additional relationship data.  Figure 5.  Every object in OpenMe has an implicit has relationship (Section 3.2.3) to the OSN object, which is a singleton. A number of arbitrary objects are shown in this figure. All other relationships between the objects are not shown. Additionally, relationships may contain two optional pieces of data. The first is that relationships themselves may contain additional data that describes the relationship, such as the date the relationship was created or a label to apply to that relationship.  The second is a relationship object.  A relationship object is an object that is tied to the target object.  In other words, it cannot exist if the target object no longer exists.  This is in contrast with regular objects, which can exist outside a relationship.  An example of a relationship object is a Comment object.  A comment must be made on an already existing (target) object and if the target object no longer exists, then the comment cannot exist. Finally, all OpenMe objects, including relationship objects, have an implicit relationship with a singleton object called the OSN object (Figure 5).  The relationship used is a has relationship (see Section 3.2.3 for more information).  The primary purpose of having this connection from all 16 OpenMe objects to the OSN object is to provide a way to reach any object within the OSN from the root level.  An example of a use case for this is if one wanted to search for a specific user within an OSN. By having relationships abstract the actions that occur within OSNs, we hide the low level details of how OSN specific objects are connected to one another, as they are often inconsistent.  For example, Figure 6a shows the concept of posting a photo in various OSNs.  In Twitter, photos can only be posted on Tweets, but can be tagged so as to group them.  In Facebook, a photo can be added to a photo album.  In Foursquare, a photo can be added to a venue, which is a location or place on a list, which is a grouping of venues.  Each of the aforementioned social networks has very different objects and connections, even though the actions taken to create those connections are very similar. To express this in OpenMe, we must use the appropriate relationship in this context.  OpenMe provides a categorization of relationships depending on what they do.  In this case we are creating a photo, which falls under the Content (Section 3.2.2) relationships category.  This category provides a relationship called posted-photo-on, which describes that a source object has posted a photo on a target object (Figure 6b). The source object in this case is a User and the target object is a Collection, which is an object in OpenMe that abstracts a list of objects and fits in this case as the target object. Note that it is not always possible to express actions in multiple OSNs with one relationship.  In this example the user was the same in all three OSNs and the OpenMe target object was able to abstract where the photo was posted in each OSN.  If the users were different or more than one target object type was needed, then we would have required more relationships, but all of them would still be a posted-photo-on relationship. 17  Figure 6.  Detailed example of how an instance of an OpenMe graph and three OSN specific graphs map to each other.  Selected data is shown on each object. 3.1.2 Using Relationships The main purpose of OpenMe is to provide a language that apps can use to interface with social networks.  Generally this involves reading and writing OSN data on behalf of a user.  OpenMe achieves this by allowing the direct manipulation of its relationships representative of functional programming.  Each OpenMe relationship may support one or more of a create, read, update, or delete action, also known as CRUD [33]. Whenever a social network that OpenMe is abstracting changes, its changes will be reflect in the OpenMe graph.  On the other hand, whenever the OpenMe graph changes, its meaning will be propagated down to each OSN it is abstracting, with each OSN performing the appropriate actions that represent the high level change in OpenMe.  This section presents the general structure of each of the CRUD actions for a relationship. 18 3.1.2.1 General Relationship Usage Every CRUD action applied to a relationship has some common concepts. In each of these relationship manipulations, a source object and target object need to be specified.  Each of these objects may be either an object type or an object instance.  An object type is analogous to the class of an object in object-oriented programming.  For example, User is an object type, and an instance of a User object in OpenMe is its ID, such as U_34594410.  Specifying an object type as the source and/or target objects in a relationship essentially represent a wildcard and will match relationships that exist in OpenMe where the source and/or target object is of that type. Also, each CRUD action on a relationship can specify the exact OSNs that OpenMe will use when evaluating the CRUD action for that relationship.  For example if a create action is called on a relationship, one could specify that this action only affect Facebook.  This way, only Facebook would interpret the high level OpenMe relationship and be affected even if OpenMe is abstracting many other OSNs at the same time.  Lastly, every relationship may be negated with the ‘!’ symbol to denote that the CRUD action on a relationship should apply to everything other than what is specified in the relationship.  This has very limited use cases. 3.1.2.2 Creating a Relationship Creating OpenMe relationships allows for the creation of data on OSNs OpenMe is abstracting.  This may be writing new data to the OSNs such as a new status message, photo, or video.  Or this could be modifying existing objects in the OSN such as two users becoming friends.  For example if a relationship indicating that a user had posted a photo on a collection in OpenMe, then OpenMe would attempt to perform actions in the OSNs it is abstracting that would achieve the same meaning as the 19 high level relationship that was just created.  Not all relationships can be created. create_relationship(relname,	
  source,	
  target	
  [,	
  relationship_object]	
  [,	
   relationship_data]	
  [,	
  osns])	
   relname	
  –	
  The	
  name	
  of	
  the	
  relationship	
  to	
  create.	
   source	
  –	
  The	
  object	
  type	
  or	
  object	
  instance	
  that	
  is	
  performing	
  the	
   action	
  described	
  in	
  the	
  relationship.	
   target	
  –	
  The	
  object	
  type	
  or	
  object	
  instance	
  that	
  the	
  action	
  is	
  being	
   acted	
  on.	
   relationship_object	
  –	
  An	
  object	
  that	
  is	
  created	
  as	
  part	
  of	
  this	
   relationship	
  creation.	
   relationship_data	
  –	
  Additional	
  data	
  that	
  describes	
  the	
  relationship.	
   osns	
  –	
  The	
  OSNs	
  that	
  OpenMe	
  is	
  abstracting	
  in	
  which	
  the	
  creation	
  of	
   this	
  relationship	
  will	
  be	
  propagated	
  to.	
   	
   Returns:	
  	
  A	
  message	
  indicating	
  success	
  or	
  failure.	
   	
   Example:	
   The	
  authenticated	
  user	
  posts	
  a	
  photo	
  on	
  his	
  or	
  her	
  own	
  space	
  in	
  a	
   social	
  network.	
  	
  The	
  relationship	
  object	
  is	
  a	
  photo	
  object	
  that	
   contains	
  two	
  fields:	
  (1)	
  the	
  byte	
  data	
  of	
  the	
  photo,	
  and	
  (2)	
  the	
  name	
   of	
  the	
  photo.	
   	
   create_relationship(‘posted-­‐photo-­‐on’,	
  me,	
  me,	
  {data:	
  byte[],	
  name:	
  ‘my	
   first	
  photo!’}))	
   3.1.2.3 Reading a Relationship Reading OpenMe relationships allows for the retrieval of information from the OSNs that OpenMe is abstracting.  This may be retrieving the friends a specific user has, the photos a user has posted on a collection, or the number of events a user is planning to attend.  For example if a relationship was read that described that a user is friends with another user, OpenMe would query the OSNs it is abstracting for their interpretation of that relationship and combine and aggregate the results. All relationships can be read.  20 read_relationship(relname,	
  source,	
  target	
  [,	
  query]	
  [,	
  osns])	
   relname	
  –	
  The	
  name	
  of	
  the	
  relationship	
  to	
  read.	
   source	
  –	
  The	
  object	
  type	
  or	
  object	
  instance	
  that	
  is	
  performing	
  the	
   action	
  described	
  in	
  the	
  relationship.	
   target	
  –	
  The	
  object	
  type	
  or	
  object	
  instance	
  that	
  the	
  action	
  is	
  being	
   acted	
  on.	
   query	
  –	
  A	
  list	
  of	
  key-­‐value	
  pairs	
  that	
  filter	
  on	
  relationships	
  to	
   return	
  where	
  the	
  keys	
  are	
  from	
  the	
  relationship	
  data	
  or	
   relationship	
  object.	
   osns	
  –	
  The	
  OSNs	
  that	
  OpenMe	
  is	
  abstracting	
  whose	
  data	
  will	
  be	
  used	
  in	
   this	
  relationship	
  read.	
   	
   Returns:	
  	
  A	
  relationship	
  object	
  or	
  objects	
  containing	
  data	
  on	
  the	
   source	
  and	
  target	
  object(s),	
  any	
  relationship	
  objects,	
  and	
  any	
   relationship	
  data.	
   	
   Example:	
   Retrieving	
  users	
  a	
  user	
  knows	
  that	
  mutually	
  acknowledge	
  they	
  know	
  the	
   user.	
  	
  The	
  target	
  is	
  specified	
  as	
  an	
  object	
  type	
  as	
  to	
  return	
  all	
  users	
   that	
  have	
  this	
  relationship	
  with	
  the	
  source	
  user.	
   	
   read_relationship(‘is-­‐mutual-­‐with’,	
  me,	
  User)	
   3.1.2.4 Updating a Relationship Similar to creating a relationship.  Updating a relationship allows an existing relationship to be edited.  For example, an OpenMe relationship that indicates a user is a friend of another user may be updated to say that a user is not dating that other user.  This will then propagate to all OSNs OpenMe is abstracting to update the appropriate objects in those OSNs to achieve the same meaning as the OpenMe high-level relationship. Not all relationships can be updated. update_relationship(relname,	
  source,	
  target	
  [,	
  relationship_object]	
  [,	
   relationship_data]	
  [,	
  osns])	
   relname	
  –	
  The	
  name	
  of	
  the	
  relationship	
  to	
  update.	
   source	
  –	
  The	
  object	
  type	
  or	
  object	
  instance	
  that	
  is	
  performing	
  the	
   action	
  described	
  in	
  the	
  relationship.	
   target	
  –	
  The	
  object	
  type	
  or	
  object	
  instance	
  that	
  the	
  action	
  is	
  being	
   acted	
  on.	
   21 relationship_object	
  –	
  The	
  updated	
  relationship	
  object.	
   relationship_data	
  –	
  Updated	
  relationship	
  data.	
   osns	
  –	
  The	
  OSNs	
  that	
  OpenMe	
  is	
  abstracting	
  in	
  which	
  the	
  update	
  of	
  this	
   relationship	
  will	
  be	
  propagated	
  to.	
   	
   Returns:	
  	
  A	
  message	
  indicating	
  success	
  or	
  failure.	
   	
   Example:	
   A	
  ‘knows’	
  relationship	
  describes	
  that	
  a	
  user	
  knows	
  another	
  user	
  and	
   contains	
  a	
  string	
  label	
  as	
  part	
  of	
  its	
  relationship	
  data	
  to	
  describe	
   how	
  the	
  user	
  knows	
  the	
  other	
  user.	
   	
   update_relationship(‘knows’,	
  me,	
  ‘Angela’,	
  null,	
  ‘label=is-­‐dating’)	
   3.1.2.5 Deleting a Relationship Deleting OpenMe relationships allows for data to be deleted in the OSNs OpenMe is abstracting.  An OpenMe relationship that is deleted will propagate to those OSNs who will delete the appropriate objects and/or connections depending on the OSN’s interpretation of the high level OpenMe relationship. delete_relationship(relname,	
  source,	
  target,	
  [,	
  query]	
  [,	
  osns])	
   relname	
  –	
  The	
  name	
  of	
  the	
  relationship	
  to	
  create.	
   source	
  –	
  The	
  object	
  type	
  or	
  object	
  instance	
  that	
  is	
  performing	
  the	
   action	
  described	
  in	
  the	
  relationship.	
   target	
  –	
  The	
  object	
  type	
  or	
  object	
  instance	
  that	
  the	
  action	
  is	
  being	
   acted	
  on.	
   query	
  –	
  A	
  list	
  of	
  key-­‐value	
  pairs	
  that	
  filter	
  on	
  relationships	
  to	
   delete	
  where	
  the	
  keys	
  are	
  from	
  the	
  relationship	
  data	
  or	
   relationship	
  object.	
   osns	
  –	
  The	
  OSNs	
  that	
  OpenMe	
  is	
  abstracting	
  in	
  which	
  the	
  delete	
  of	
  this	
   relationship	
  will	
  be	
  propagated	
  to.	
   	
   Returns:	
  	
  A	
  message	
  indicating	
  success	
  or	
  failure.	
   	
   Example:	
   A	
  user	
  deletes	
  a	
  specific	
  photo	
  from	
  a	
  collection.	
   	
   delete_relationship(‘posted-­‐photo-­‐on’,	
  me,	
  ‘summer	
  vacay	
  2009’,	
   ‘Photo.id=P_4df24jff0’)	
   22 3.2 OpenMe Relationships and Types OpenMe provides a number of relationships that are able to map down to OSN specific functions.  Each of these relationships falls under a relationship category.  Each category houses relationships that have a similar purpose and/or semantics and also help organize the OpenMe language.  Relationships under a category can also form a hierarchy.  A relationship may have various other relationships inherit from it.  These sub-relationships have similar semantics to their parent, but usually are more specific.  This hierarchy is purely for organization as each relationship is independent from one another.  That is, reading, creating, updating, or deleting a parent relationship does not affect its children. Relationships may also have convenience relationships called aliases that are named differently, but ultimately have the same semantics as the original relationship.  In this section we describe each of the relationship categories and the semantics of the relationships it houses.  A legend for the symbols used in the hierarchy diagrams is shown in Figure 7.  Figure 7.  Legend that describes the symbols used in the relationship hierarchy diagrams shown in the following sections. Note that the relationships defined here are an initial set we have developed.  Because the nature of creating abstractions is subjective, the organization of the OpenMe relationships presented here may not be 23 optimal.  In any case, the strength of these relationships lies in their architectural style as discussed in the previous section.  OpenMe relationships are expected to change time and new ones may be added and existing ones expanded or deprecated to reflect evolving social networks. 3.2.1 Roles  Figure 8.  Role relationships and their hierarchal structure. Role relationships define what part a user plays in another object’s existence.  There are three groups within the role relationships category. Figure 8a show the first group containing relationships that can only exist between objects where both the source and target objects are User 24 objects.  The two main relationships in this group are knows and is- mutual-with.  The is-mutual-with relationship exists between two users if both users define a mutual role with one another in an OSN.  Nothing is said about what this role is, but means they mutually acknowledge one another in the OSN. The knows relationship describes the role a user plays in another user’s life.  For example a user may define a knows relationship to another user with the label “co-workers” to indicate that the target user is a co-worker of the source user.  This essentially affords the ability to group users a user knows within OSNs. The is-family relationship is also another way for users to label other users, except it has different semantics or meaning than the knows relationship in the sense that some OSNs such as Facebook treat family labels differently.  Extending the is-family relationship are is-sibling, is-child, and is-parent.  These relationships hold access control list (ACL) settings in their semantics.  It is common for parents to have access to their children’s activities and children not to have access to their parent’s [65].  This is common even outside the area of OSNs [64]. Similarly, the is-sibling relationship implies that all siblings have access to view one another’s information.  Because of this, it must be noted that is- family with a label of brother, i.e.:  is-family(“brother”), has a different meaning than is-brother-of.  The former does not imply any ACL settings, only the meaning of family in an OSN, but the latter implies both family as well as ACL settings. Figure 8b shows relationships that can occur between a User object and any target object in an OSN.  The two relationships in this group are follows and in-charge-of.  The follows relationship means that a user is interested in the content of another user or object, and thus “follows” or subscribes to it.  The in-charge-of relationship is an abstract relationship that can be read, but cannot be created.  Instead, it has two sub relationships that can be created.  The is-owner-of relationship means that the user was the creator of the target object, and thus owns 25 it.  This often implies the sole ability to destroy it or transfer ownership. The is-manager-of relationship means that the user administers the target object, and generally has less rights than the owner, making these two relationships different from one another.  These kinds of roles are often seen in collaborative document features or file systems, such as Google Docs15, which does have some social features. Lastly, Figure 8c shows the is-part-of relationship, which can only occur between users and non-user objects.  This relationship defines a role a user takes in an object.  Common examples are shown through the alias relationships, such as being a student, employee, or member of an object. In these cases the target objects are typically a school, company, or group, respectively. 3.2.2 Content  Figure 9.  Content relationships and their hierarchal structure. Like roles, content is a major defining factor of an OSN [24, 42].  The content category contains relationships that generally deal with information or data that has been created by users in the social network.  15 http://docs.google.com 26 Content relationships are split into five groups because of the varying combinations of user and non-user objects in these relationships.  Figure 9a shows the sent-message-to relationship, which is the only content relationship that exists solely between two User objects.  The semantics of this relationship indicate a private message is sent from the source user to the target user. Figure 9b holds the main relationships of this category, which are relationships relating to the creation of content in OSNs.  We abstract content creation using the relationship posted-on, which indicates that a user has posted an object onto another user or non-user object.  The object being posted is referred to as a relationship object, which are objects that can only exist if the target object they were posted on exists. That is, the target object houses the content.  Some examples of target objects are a user’s personal space in the OSN, a representation of a place, an event, a group, or a collection. The posted-on relationship also contains a number of sub- relationships.  The relationships posted-photo-on, posted-video-on, and posted-url-on define specific objects that are created.  The shared-on relationship describes a user sharing an existing piece of content on a target object (e.g.:  another user, event, or group).  The commented-on relationship describes a user posted text that represents a comment on a non-user object. Figure 9c shows relationships that can only exist between user and non-user objects.  The likes relationship defines a positive rating that the user gives to the non-user object, such as a Photo object.  The added-to relationship defines that a user has added an object to another object. This could be used to describe adding a Photo object to a collection for example.  The created relationship defines creating new content in an OSN that does not need to be attached to a target object unlike the posted-on relationship.  This can be used to create an Event object for example, which often can exist as an entity in an OSN even if ties to the user who created it are severed. 27 Figure 9d shows the is-tagged-in content relationship, which can have both user and non-user objects as its source and only non-user objects as its target.  This relationship is used to define references that exist in non- user objects that are made to users or other non-user objects.  For example, a post in an OSN may contain references to other users and places if somebody writes that he or she is at a specific place with specific users.  The users and places will be “tagged” in that post. Lastly, Figure 9e shows one of the most important content relationships, which is a relationship that defines what content a user sees in his or her newsfeed.  Newsfeed are an integral part of OSNs [13, 55] and consist of content made by a user or others that appear in a timeline for a specific user or object such as an Event.  Also, it is common in OSNs filter content that appear on a user’s timeline or newsfeed by what the user is interested in.  Thus, the objects the is-in-newsfeed-of relationship exists between is often changing. 3.2.3 OSN  Figure 10.  OSN relationships and their hierarchal structure. As mentioned previously in Section 3.1.1 in Figure 5, there exists a special relationship called the has relationship that connects all OpenMe objects to a singleton object in OpenMe called “OSN”.  This relationship simply describes that an object exists in an OSN and is used primarily to abstract querying functionality.  For example, all User objects have a has relationship between the OSN object and the User object.  We can then search for users named “Astro Teller” by querying this has relationship and specifying the target user object’s name to be “Astro Teller” in a relationship query parameter. 28 read_relationship(‘has’,	
  OSN,	
  User,	
  User.firstName=‘Astro’,	
   User.lastName=‘Teller’)	
   3.2.4 Location  Figure 11.  Location relationships and their hierarchal structure. Support for location models are becoming a very important part of many OSNs and essential for some OSNs such as Foursquare.  It has so far become one of the easiest and most useful pieces of context aware data to obtain from a user.  Hence we have placed relationships that deal with describing location between two objects in its own category. Figure 11a shows the relationships is-located-at and was-located- at that represent where a user is or was located at and at what time. This abstraction of location treats it more like a description and less like an object, which allows us to better abstract the different location models found across OSNs.  The is-located-at relationship describes the current location of a user whereas the was-located-at describes stale locations. Each OSN may determine the “freshness” of a location different (i.e.: using different expiry thresholds). Figure 11b shows the relationship is-near, which can have only User objects as its source, but both User and non-user objects as its target. This relationship describes things that are near a specified user.  A common example is the retrieval of places (shops, hotels, restaurants, etc.) that are near a user given the user’s current location.  Knowing what is near a user is an important part of ubiquitous computing and mobile social networking [47] and we expect to see even more usage of it in future OSNs. 29 3.2.5 Desires and Deeds  Figure 12.  Desires and deeds relationships and their hierarchal structure. Many OSN actions can be classified as something an object wants to do or something and object has done, with the source object usually being a user.  We refer to these as desires and deeds, respectively.  The relationships in this category abstract a wide range of functionality that exists in OSNs. Figure 12 shows the three main relationships in this category:  wants- to, will, and has.  Each of these relationships is abstract and can be read, but not created.  Each also contains a relationship property called “as”, which specifies the role a user takes in the relationship.  For example a user may want to do something as a student, as a post doc, or as a tourist.  These abstract relationships allow the retrieval of all things a user wants to do, will do, or has done in an OSN and optionally, the role the user wants to do it as, will do it as, or has done it as. 30 The rest of the relationships in this category consist of sub relationships of the three main relationships described above.  Each of these sub relationships describes a different action the user wants-to do, will do, or has done.  The wants-to-be-mutual-with relationship can only exist between users and describes that a user wants another user to acknowledge that they know each other mutually.  The wants-to-visit, will-visit, has-visited, and wants-to-follows relationships can have both user and non-user objects as their targets.  For example users can visit or follow their friends and visit or follow a company.  The wants-to- follow relationship describes content that the user does not have access to and desires to have access to. The two remaining relationships can only take in non-user objects as their targets.  The part-of relationships have similar semantics to the is- part-of role relationship, except these ones represent wanting-to, will- be, or has-been part of something instead of a user being currently part of something.  Lastly, the wants-to-complete, will-complete, and completed relationships describe objects that contain requirements that a user can complete.  These can be things like a tip another user posted on a restaurant that the user wants to try.  Or it can be a class the user took or a degree the user wants to finish. 3.2.6 Permissions and Collaboration  Figure 13.  Permissions and collaboration relationships and their hierarchal structure. There are often circumstances where deriving access control from role relationships is not sufficient and OSNs require a richer set of permissions. 31 These can occur with things like online communities or groups and online documents.  For example, group members may all be able to read posts made by other group members in a restricted group due to their role as member.  But, certain members may have more privileges than other members.  The permissions and collaboration relationships category (Figure 13) houses basic access control relationships such as can-read, can-edit, and can-delete that override default permissions from role relationships in OSNs that support them. Because these types of permission relationships are so common in collaboration settings, collaboration relationships are also housed in this category.  These relationships abstract functionality that deal with multiple users editing the same object.  They consist of is-reading, has- read, is-editing, and has-edited and are consistent across most OSNs that have collaboration [66]. 3.3 Summary In this section we have introduced the OpenMe OSN abstractions that apps can use to interface with multiple OSNs.  We described the structure of these abstractions as a graph that contains data objects as nodes and a description of how two nodes are connected, called relationships, as its edges.  These relationships essentially abstract the actions that can occur between objects in OSNs.  We then described how these relationships can be read, created, updated, and deleted to push or pull information from the underlying OSNs OpenMe is abstracting.  Based on the semantics of the relationship, OpenMe translates the meaning of the relationship to functionality in each OSN it is abstracting. The latter portion of this chapter introduced the categories of relationships OpenMe provides.  In each category, a diagram was given that explained with what source and target objects a relationship could be used with and described and relationship hierarchy.  We then discussed the semantics of each relationship for each category. 32 Chapter 4 Evaluation In order to determine the strength of the OSN abstractions we have presented, we evaluate them against certain criteria.  Typically, abstractions are evaluated on their readability, expressiveness, inference/reasoning, and feasibility [15].  For the first iteration of the OpenMe abstractions, we have chosen to focus on evaluating their expressiveness and feasibility.  These two metrics are most important because they validate the concept of the OpenMe abstractions. Readability and inference/reasoning focus more on user experience, which we leave for future iterations of the OpenMe abstractions after we have proved that they are useful and feasible.  This chapter presents the methodology we used to evaluate both metrics followed by results and discussions. 4.1 Expressiveness The expressiveness of our OSN abstractions determines how much of the functionality in existing OSNs can be represented by the OpenMe abstractions.  A strong set of abstractions will be able to cover a majority of what one is able to do given a specific OSN, particularly the functionalities of an OSN that are used the most. In the first iteration of OpenMe, we do not aim to cover 100% of all OSN functionality.  There are certain categories of functionality that we chose not to target for our initial set of abstractions as we did not see these as the most important functionalities that apps would use [3, 58]. Table 1 shows a list of these functionality categories. 33 Table 1.  OSN functionality not supported in this version of OpenMe. Functionality Comment notifications third party apps e.g.:  Facebook developer game related achievements, badges, scores, leaderboards statistics related e.g.:  Facebook insights, Foursquare manager tools payment related microtransactions business related company profiles, company accounts miscellaneous objects specific to Facebook e.g.:  notes, questions user feedback user reviews, spam/inappropriate content flagging help related e.g.:  Twitter exposes API endpoints for help real time update callback services e.g.:  Facebook subscriptions, Twitter streams anything that is marked experimental anything that is marked deprecated batching functionality user settings OAuth endpoints legal material e.g.:  Twitter exposes API endpoints for legal advanced querying functionality e.g.:  FQL With the remaining functionality, our initial goal is to have created abstractions that cover around 80% of these in a variety of OSNs, which includes the most used functionality by apps.  The remaining 20% are therefore generally edge cases, which the OpenMe abstractions can be easily extended to cover in future iterations.  The focus of this iteration is to show a strong initial coverage and implement some of those relationships to provide a comprehensive proof of concept.  This section presents our methodology for measuring OSN functionality coverage, examples of how OpenMe relationships represent OSN functionalities, and results showing that we have achieved our goal of an 80% coverage in this iteration of OpenMe. 34 4.1.1 Methodology We evaluated the expressiveness of the OpenMe abstractions against three popular OSNs [16, 49]:  Foursquare, Facebook, and Twitter.  We also chose these three in particular because the way each presents itself is unique, although we will see through this evaluation that the actions one can perform in each of these OSNs has a large intersect. Our method consisted of examining each endpoint in each of Foursquare, Facebook, and Twitter’s APIs and trying to represent the meaning of executing the endpoint with an OpenMe relationship.  For example, the Facebook API exposes the endpoint “GET /PHOTO_ID/comments”, which returns the comments on the specified photo.  We then see if there is an OpenMe relationship that represents the same meaning as the Facebook endpoint.  In this case the OpenMe relationship “commented-on” is able to do this.  We chose to test the OpenMe relationships against the OSN API endpoints because these are the functionalities third party apps have access to.  Thus if we are able to show a large coverage of these endpoints, then we can conclude that third party apps can do just as much with OpenMe as with interfacing with the OSNs natively. 4.1.2 OpenMe Relationships to OSN Endpoints Mapping In this section we demonstrate how API endpoints in Foursquare, Facebook, and Twitter can be represented by OpenMe relationships. Because of the large number of endpoints each of the OSN APIs have, even with the above categories omitted, we will only show a selection of this mapping.  The full mapping of OpenMe relationships to Foursquare, Facebook, and Twitter functionality can be found in Appendix B. This selection covers some mappings from role and content relationships as those are the most common types of functionality in OSNs [3, 58].  We also show select mappings from location and desires and deeds relationships to demonstrate some edge cases.  Mappings are 35 organized by OpenMe relationships to demonstrate many OpenMe relationships can map down to a large number of OSN endpoints.  Table 2 shows the shorthand that is used when describing the mappings in this section and in Appendix B as well. Table 2.  Legend of abbreviations used in the following tables in the interest of space. c = create_relationship(...) r = read_relationship(...) u = update_relationship(...) d = delete_relationship(...) {value} = arbitrary value ... = additional parameters, sometimes optional value1 | value2 = either value1 or value 2 is accepted FS = Foursquare FB = Facebook TW = Twitter 4.1.2.1 Roles OpenMe role relationships abstract what part a user plays in the life of another user or object.  Because of this, role relationships are good for abstracting the different “friend” model functionality found in the OSNs we surveyed. Table 3 shows the is-mutual-with relationship that can be used in different ways to represent the functionality of friend management in social networks.  The semantics of the is-mutual-with relationship defines a mutual role between two users, but does not state what that role is.  (1) shows how this can be used to find all other users who share a mutual relationship with a specified user.  (2) shows how to request a mutual relationship between two specific users.  (3) shows how to remove a mutual relationship between two specific users.  (4) how to use this relationship to see if a mutual relationship exists between two specific users. 36 Table 3.  Select OSN specific functionality that the OpenMe is-mutual-with relationship can abstract. is-mutual-with # Usage OSN API Endpoint OSN (1) r(‘is-mutual-with’, {USER_ID}, User) GET /users/USER_ID/friends FS GET /USER_ID/friends FB GET /friends/ids TW (2) c(‘is-mutual-with’, {USER_ID}, {USER_ID_TO_REQUEST}) POST /users/USER_ID_TO_REQUEST/request FS (3) d(‘is-mutual-with’, {USER_ID}, {USER_ID_TO_UNFRIEND}) POST /users/USER_ID/unfriend FS (4) r(‘is-mutual-with’, {USER_ID}, {USER_ID}) GET /friendships/exists TW GET /friendships/show TW GET /PROFILE_ID/friends/FRIEND_ID FB The role relationships also provide a follows relationship (Table 4), which implies a unidirectional indication that a user is interested in the content of another user or object.  This is like a subscription.  In some OSNs such as Twitter, two users following one another automatically mean they are “friends” or acknowledge a mutual role with one another. In other OSNs like YouTube and Facebook, this is not the case.  (1) and (2) show how this relationship can be used to state a specified user follows another user or collection.  (3) and (4) show how to retrieve all the users or collections that a specified user follows.  (5) and (6) show how to retrieve all the users that follow a specified user or collection. Table 4.  Select OSN specific functionality that the OpenMe follows relationship can abstract. follows # Usage OSN API Endpoint OSN (1) c(‘follows’, {USER_ID}, {USER_ID_TO_FOLLOW}) POST /users/USER_ID_TO_FOLLOW/request FS POST /friendships/create TW (2) c(‘follows’, {USER_ID}, {COLLECTION_ID}) POST /lists/LIST_ID/follow FS POST /lists/subscribers/create TW (3) r(‘follows’, {USER_ID}, User) GET /friends/ids TW GET /USER_ID/subscribedto FB 37 follows # Usage OSN API Endpoint OSN (4) r(‘follows’, {USER_ID}, Collection) GET /lists/all TW (5) r(‘follows’, User, {USER_ID}) GET /followers/ids TW GET /USER_ID/subscribers FB (6) r(‘follows’, User, {COLLECTION_ID}) GET /lists/LIST_ID/followers FS GET /lists/subscribers TW To describe role relationship functionality between users such as friend lists in Facebook and Twitter, and family in Facebook, we use the OpenMe relationship knows and is-family respectively (Table 5).  (1), (2), (3), (4) shows how the knows relationship allows one user to place, create, update, or delete a label that describes how he or she knows another user, essentially placing that other user into a group.  (5) shows how to retrieve all the different labels in roles that other users have defined with that user.  Table 6 (1) shows the is-family relationship does the same thing, except its semantics imply that the two users are kin, which can result in some OSNs like Facebook treating the relationship differently. Table 5.  Select OSN specific functionality that the OpenMe knows relationship can abstract. knows # Usage OSN API Endpoint OSN (1) d(‘knows’, {USER_ID}, {USER_ID_TO_REMOVE}, label={LIST_NAME}) POST /lists/members/destroy TW DELETE /FRIENDLIST_ID/members/USER_ID FB (2) r(‘knows’, {USER_ID}, User, label={LIST_NAME}) GET /lists/members TW GET /lists/show TW GET /FRIENDLIST_ID/members FB (3) c(‘knows’, {USER_ID}, {USER_ID_TO_ADD}, label={LIST_NAME}) POST /lists/members/create TW POST /FRIENDLIST_ID/members/USER_ID FB (4) u(‘knows’, {USER_ID}, User, label={LIST_NAME}, ...) POST /lists/update TW (5) r(‘knows’, User, {USER_ID}) GET /lists/memberships TW  38 Table 6.  Select OSN specific functionality that the OpenMe is-family relationship can abstract. is-family # Usage OSN API Endpoint OSN (1) r(‘is-family’, {USER_ID}, User) GET /USER_ID/family FB Table 7 shows the is-part-of relationship abstracting OSN endpoints that deal with users being part of non-user objects on social networks. These are things such as online communities or groups, and events.  (1) and (2) show how this relationship can be used to add or remove a user to and from an event.  (3) and (4) shows how to retrieve which users are invited to a specific event or a member of a specific group.  (5) uses this relationship to retrieve all the groups a specified user is a member of.  (6) shows that we can even use this relationship to represent mayorships in Foursquare, which at first seems like a very OSN specific functionality, but upon further analysis can be described by an is-part-of relationship. Table 7.  Select OSN specific functionality that the OpenMe is-part-of relationship can abstract. is-part-of # Usage OSN API Endpoint OSN (1) c(‘is-part-of’, {USER_ID}, {EVENT_ID}) POST /EVENT_ID/invited/USER_ID FB (2) d(‘is-part-of’, {USER_ID}, {EVENT_ID}) DELETE /EVENT_ID/invited/USER_ID FB (3) r(‘is-part-of’, User, {EVENT_ID}) GET /EVENT_ID/invited FB (4) r(‘is-part-of’, User, {GROUP_ID}) GET /GROUP_ID/members FB (5) r(‘is-part-of’, {USER_ID}, Group) GET /USER_ID/groups FB (6) r(‘is-part-of’, {USER_ID}, Place, label=’mayor’) GET /users/USER_ID/mayorships FS 4.1.2.2 Content Social networks often have similar concepts of content manipulation, but differ in where content can reside within each OSN.  For this, the 39 OpenMe content relationships allow the flexibility to explicitly specify where the content should reside for a relationship that manipulates it. This allows us to abstract a number of OSN endpoints with each content manipulation relationship by simply changing the target object of the relationship. Table 8 shows the posted-photo-on relationship abstracting OSN endpoints that specifically deal with creating photos.  (1) shows how this relationship can be used to retrieve photos a user has posted on any object in an OSN.  (2) shows how a single photo can be retrieved using the photo’s ID as a query parameter.  (3) shows how a photo can be created on an OSN and posted to a user’s personal space or timeline on the OSN.  (4), (5), (6), (7) show this relationship being used to retrieve and create photos on various non-user objects. Table 8.  Select OSN specific functionality that the OpenMe posted-photo-on relationship can abstract. posted-photo-on # Usage OSN API Endpoint OSN (1) r(‘posted-photo-on’, {USER_ID}, Object) GET /users/USER_ID/photos FS (2) r(‘posted-photo-on’, User, Object, Photo.id={PHOTO_ID}) GET /photos/PHOTO_ID FS GET /PHOTO_ID FB (3) c(‘posted-photo-on’, {USER_ID}, {USER_ID}, Photo.desc={DESC}, Photo.data=byte[], ...) POST /statuses/update_with_media TW POST /PROFILE_ID/photos FB (4) r(‘posted-photo-on’, User, {PLACE_ID}) GET /venues/VENUE_ID/photos FS (5) c(‘posted-photo-on’, {USER_ID}, {LOCATION_ID}, Photo.name={NAME}, Photo.data=byte[], ...) POST /photos/add FS (6) r(‘posted-photo-on’, {USER_ID}, {COLLECTION_ID}) GET /ALBUM_ID/photos FB (7) c(‘posted-photo-on’, {USER_ID}, {EVENT_ID}, Photo.name={PHOTO_NAME}, Photo.data={BYTE[]}, ...) POST /EVENT_ID/photos FB 40 Table 9 shows the likes relationship abstracting OSN endpoints that deal with rating content.  (1), (2), (3), (4), (5), and (6) show how the relationship can be used to retrieve which users like a certain object and specify that a user likes a certain object.  These can include objects such as albums, events, comments, and posts as shown in the table.  (7) shows how this relationship can be deleted to “unlike” something that a user has previously liked.  (8) shows how to retrieve all the objects a user has liked. Table 9.  Select OSN specific functionality that the OpenMe likes relationship can abstract. likes # Usage OSN API Endpoint OSN (1) r(‘likes’, User, {COLLECTION_ID}) GET /ALBUM_ID/likes FB (2) c(‘likes’, {USER_ID}, {COLLECTION_ID}) POST /ALBUM_ID/likes FB (3) r(‘likes’, User, {COMMENT_ID}) GET /COMMENT_ID/likes FB (4) c(‘likes’, {USER_ID},{COMMENT_ID}) POST /COMMENT_ID/likes FB (5) r(‘likes’, User, {POST_ID}) GET /POST_ID/likes FB GET /STATUS_ID/likes FB (6) c(‘likes’, {USER_ID},{POST_ID}) POST /POST_ID/likes FB POST /STATUS_MESSAGE_ID/likes FB POST /statuses/retweet/:id TW (7) d(‘likes’, {USER_ID}, {POST_ID}) DELETE /POST_ID/likes FB DELETE /STATUS_MESSAGE_ID/likes FB (8) r(‘likes’, {USER_ID}, Object) GET /USER_ID/likes FB Table 10 shows the shared-on relationship abstracting OSN endpoints that deal with sharing content.  (1) shows how this relationship can be used to share objects, such as a collection, with another user on specific social networks specified in the query parameters of the relationship.  (2) and (3) show how to retrieve all content that a specific user or any user has shared with a specific target user.  (4) shows how this relationship can retrieve a specific piece of shared content and (5) shows how to share a piece of content with another user. 41 Table 10.  Select OSN specific functionality that the OpenMe shared-on relationship can abstract. shared-on # Usage OSN API Endpoint OSN (1) c(‘shared-on’, {USER_ID}, {USER_ID}, Collection.id={COLLECTION_ID}, osns=’facebook,twitter’) POST /lists/LIST_ID/share FS (2) r(‘shared-on’, {USER_ID}, {USER_ID}) GET /statuses/retweeted_by_me TW GET /statuses/retweeted_by_user TW (3) r(‘shared-on’, User, {USER_ID}) GET /statuses/retweeted_to_me TW GET /statuses/retweeted_to_user TW (4) r(‘shared-on’, User, User, Post.id={POST_ID}) GET /statuses/:id/retweeted_by TW GET /statuses/:id/retweeted_by/ids TW GET /statuses/retweets/:id TW (5) c(‘shared-on’, {USER_ID}, {USER_ID}, Post.id={POST_ID}) POST /statuses/retweet/:id TW Table 11 shows the is-in-newsfeed-of relationship abstracting OSN endpoints that deal with content in newsfeeds.  (1) shows how this relationship can be used to retrieve content in a user’s newsfeed.  This is often for newsfeeds that are filtered by the OSN, such as in Facebook to avoid an overflow of information for the user.  Similarly, (2) and (3) show the retrieval of content in newsfeeds of non-user objects such as events and groups, found primarily in Facebook.  (4) shows how to use this relationship to retrieve custom newsfeeds by their name. Table 11.  Select OSN specific functionality that the OpenMe is-in-newsfeed-of relationship can abstract. is-in-newsfeed-of # Usage OSN API Endpoint OSN (1) r(‘is-in-newsfeed-of’, Post, {USER_ID}) GET /statuses/home_timeline TW GET /statuses/user_timeline TW GET /USER_ID/home FB (2) r(‘is-in-newsfeed-of’, Post, {EVENT_ID}) GET /EVENT_ID/feed FB (3) r(‘is-in-newsfeed-of’, Post, {GROUP_ID}) GET /GROUP_ID/feed FB 42 is-in-newsfeed-of # Usage OSN API Endpoint OSN (4) r(‘is-in-newsfeed-of’, Post, {USER_ID}, feedName={FEED_NAME}) GET /lists/statuses TW Table 12 shows the is-tagged-in relationship abstracting OSN endpoints that deal with referencing objects in content.  (1) shows how this relationship can be used to retrieve which posts a specific user is referenced in.  (2) demonstrates retrieving all users that are tagged in a specified photo.  (3) and (4) show how to tag a user in a specific photo and update the tag.  (5) and (6) show how to use this relationship to retrieve all the photos and videos a user is tagged in, respectively. Table 12.  Select OSN specific functionality that the OpenMe is-tagged-in relationship can abstract. is-tagged-in # Usage OSN API Endpoint OSN (1) r(‘is-tagged-in’, {USER_ID}, Post) GET /statuses/mentions TW GET /USER_ID/tagged FB (2) r(‘is-tagged-in’, User, {PHOTO_ID}) GET /PHOTO_ID/tags FB (3) c(‘is-tagged-in’, {USER_ID}, {PHOTO_ID}, x={X}, y={Y}) POST /PHOTO_ID/tags/USER_ID FB (4) u(‘is-tagged-in’, {USER_ID}, {PHOTO_ID}, x={X}, y={Y}) PUT /PHOTO_ID/tags/USER_ID FB (5) r(‘is-tagged-in’, {USER_ID}, Photo) GET /USER_ID/photos FB (6) r(‘is-tagged-in’, {USER_ID}, Video) GET /USER_ID/videos FB Table 13 shows the created relationship abstracting OSN endpoints that deal with creating content that does not require a target object to reside on.  For example, an Event object may be created by a user, but may still exist in the OSN if its creator is detached from the Event object. (1) shows how to use this relationship to create a place in an OSN. Places are usually things like venues and areas a user can be located at. (2) and (3) demonstrate how to use this relationship to retrieve and create a collection object.  These are objects such as lists in Foursquare, and photo albums in Facebook.  (4) shows how to retrieve a collection 43 that houses certain types of objects.  (5) shows how to create an event within an OSN. Table 13.  Select OSN specific functionality that OpenMe created relationship can abstract. created # Usage OSN API Endpoint OSN (1) c(‘created’, {USER_ID}, {PLACE_OBJECT}) POST /venues/add FS POST /geo/place TW (2) r(‘created’, User, {COLLECTION_ID}) GET /lists/LIST_ID FS (3) c(‘created’, {USER_ID}, {COLLECTION_OBJECT}) POST /lists/add FS POST /USER_ID/albums FB (4) r(‘created’, {USER_ID}, Collection, Collection.type=Photo) GET /USER_ID/albums FB (5) c(‘created’, {USER_ID}, {EVENT_OBJECT}) POST /USER_ID/events FB Table 14 shows the added-to relationship abstracting OSN endpoints that deal with adding existing content to other objects.  (1), (2), and (3) show how this relationship can be used to retrieve and add objects from and to lists, such as adding venues and tips to lists in Foursquare.  (4) demonstrates using this relationship to add documents to groups, in a similar fashion to adding items to lists. Table 14.  Select OSN specific functionality that OpenMe added-to relationship can abstract. added-to # Usage OSN API Endpoint OSN (1) r(‘added-to’, User, Collection, Object.id={PLACE_ID}) GET /venues/VENUE_ID/listed FS (2) r(‘added-to, User, Collection, Object.id={POST_ID}) GET /tips/TIP_ID/listed FS (3) c(‘added-to’, {USER_ID}, {COLLECTION_ID}, Object.id={PLACE_ID | POST_ID}) POST /lists/LIST_ID/additem FS (4) r(‘added-to’, User, {GROUP_ID}, Object.type=Document) GET /GROUP_ID/docs FB 44 4.1.2.3 Location Location functionality in OSNs commonly allows users to formally declare their position by supporting a checkin model or geographic coordinate model.  A checkin model allows users to specify that they are currently at a place or venue.  A geographic coordinate model allows users to specify their location using latitude and longitude.  Furthermore, OSNs can store user location differently.  Foursquare and Facebook have dedicated endpoints for accessing user checkins.  Twitter attaches location data to tweets and does not provide a higher-level endpoint for determining the user’s location. The following tables show the is-located-at, was-located-at, and is- near relationships abstracting OSN endpoints that deal with time and place.  This hides the underlying location model used by an OSN and where the location data is stored in the OSN.  Table 15 (1) shows how this relationship can be used to retrieve which users are currently at a specified place.  (2) shows how to define the location of a specified user. Table 16 (1) retrieves all the places a user has been to.  (2) shows information about regarding where a user was located at a specific time. (3) shows how this relationship can be used to retrieve the most recent places a user has been at.  Table 17 (1) shows how to retrieve places that are near a specified user. Table 15.  Select OSN specific functionality that the OpenMe is-located-at relationship can abstract. is-located-at # Usage OSN API Endpoint OSN (1) r(‘is-located-at’, User, {PLACE_ID}) GET /venues/VENUE_ID/herenow FS (2) c(‘is-located-at’, {USER_ID}, {PLACE_ID}) POST /checkins/add FS  45 Table 16.  Select OSN specific functionality that the OpenMe was-located-at relationship can abstract. was-located-at # Usage OSN API Endpoint OSN (1) r(‘was-located-at’, {USER_ID}, Place) GET /users/USER_ID/checkins FS GET /USER_ID/checkins FB (2) r(‘was-located-at’, {USER_ID}, Place, Location.id={LOC_ID}) GET /checkins/CHECKIN_ID FS (3) r(‘was-located-at’, {USER_ID}, Place, Location.date=RECENT) GET /checkins/recent FS Table 17.  Select OSN specific functionality that the OpenMe is-near relationship can abstract. is-near # Usage OSN API Endpoint OSN (1) r(‘is-near’, {USER_ID}, Place) GET /venues/explore FS GET /geo/search TW 4.1.2.4 Desires and Deeds The following tables show the desires and deeds relationships abstracting OSN endpoints that deal with users wanting to perform an action on an object, or have performed an action on an object.  Table 18 (1) shows how this relationship can be used to retrieve what users a specified user wants to be in a mutual role with.  (2) shows how to retrieve all the users who want to be in a mutual role with a specified user.  Table 19 (1) and (2) shows how this relationship can be used to mark or unmark content in a post that the user wants to do.  Table 20 (1) shows retrieval of all the places a user wants to visit.  Table 21 (1) which users have done the content in a post and (2) shows how to specify that a user has done content in a post.  Table 22 (1), (2), and (3) show different ways of using this relationship to retrieve which users are coming or not coming to an event.  (4) shows retrieval of all the events a user wants to attend and (5) shows how to RSVP a user to an event. 46 Table 18.  Select OSN specific functionality that the OpenMe wants-to-be-mutual relationship can abstract. wants-to-be-mutual # Usage OSN API Endpoint OSN (1) r(‘wants-to-be-mutual-with’, {USER_ID}, User) GET /users/requests FS GET /friendships/outgoing TW (2) r(‘wants-to-be-mutual-with’, User, {USER_ID}) GET /friendships/incoming TW GET /USER_ID/friendrequests FB Table 19.  Select OSN specific functionality that the OpenMe wants-to-do relationship can abstract. wants-to-do # Usage OSN API Endpoint OSN (1) c(‘wants-to-do’, {USER_ID}, {POST_ID}) POST /tips/TIP_ID/marktodo FS (2) d(‘wants-to-do’, {USER_ID}, {POST_ID}) POST /tips/TIP_ID/unmark FS Table 20.  Select OSN specific functionality that the OpenMe wants-to-visit relationship can abstract. wants-to-visit # Usage OSN API Endpoint OSN (1) r(‘wants-to-visit’, {USER_ID}, {PLACE_ID}) POST /venues/VENUE_ID/marktodo FS Table 21.  Select OSN specific functionality that the OpenMe has-done relationship can abstract. has-done # Usage OSN API Endpoint OSN (1) r(‘has-done’, User, {POST_ID}) GET /tips/TIP_ID/done FS (2) c(‘has-done’, {USER_ID}, {POST_ID}) POST /tips/TIP_ID/markdone FS Table 22.  Select OSN specific functionality that the OpenMe wants-to-attend relationship can abstract. wants-to-attend # Usage OSN API Endpoint OSN (1) r(‘wants-to-attend’, User, {EVENT_ID}) GET /EVENT_ID/attending FB 47 wants-to-attend # Usage OSN API Endpoint OSN (2) r(‘wants-to-attend’, User, {EVENT_ID}, maybe=true) GET /EVENT_ID/maybe FB (3) r(‘!wants-to-attend’, User, {EVENT_ID}) GET /EVENT_ID/declined FB (4) r(‘wants-to-attend’, {USER_ID}, Event) GET /USER_ID/events FB (5) c(‘wants-to-attend’, {USER_ID}, {EVENT_ID}) POST /EVENT_ID/attending FB 4.1.3 Discussion and Results From the OpenMe relationships to OSN functionality mapping exercise, we have shown the wide variety of OSN endpoints that OpenMe is able to cover.  We now discuss some OSN endpoints of note and which endpoints were not covered by the initial set of abstractions, followed by data to show we have reached our goal of at least 80% coverage. 4.1.3.1 OSN Endpoints of Note In our evaluation we have found certain OSN endpoints that can be supported by OpenMe, but not using OpenMe relationships or if using OpenMe relationships, contain a caveat (Table 23).  For example, Twitter and Facebook expose certain object pictures through an endpoint rather than as a property of the object.  In OpenMe they are properties of their respective object. Another example are friend list endpoints in Facebook.  In OpenMe, friend grouping is specified through the knows relationship and a friend group is not an object.  Thus, friend groups can be retrieved by querying on all the knows relationships between a specific user and other User objects.  However, this will return all knows relationships and contain non-unique labels the app using OpenMe will have to filter on its own. 48 Table 23.  OSN endpoints of note.  These endpoints may be supported in OpenMe, but not using relationships, or contain caveats. Endpoint of Note OSN Comment GET /users/profile_image/:screen_name TW profile images are returned in a User object retrieved using the has relationship between an OSN and a specific user GET /EVENT_ID/picture FB part of the Event object GET /ALBUM_ID/picture FB part of a Collection object GET /PROFILE_ID/friendlists FB friend lists are not objects in OpenMe POST /PROFILE_ID/friendlists FB friend lists are not objects in OpenMe DELETE /FRIENDLIST_ID FB friend lists are not objects in OpenMe GET /GROUP_ID/picture FB part of a Group object GET /PHOTO_ID/picture FB part of a Photo object GET /PROFILE_ID/picture FB part of a User object 4.1.3.2 Unsupported OSN Functionality OSN functionality that is not supported by the first iteration of the OpenMe abstractions are shown in Table 33 in 6B.6.  Once again these functionalities are generally edge cases that are not relevant enough to include in our initial focus.  For many of these endpoints, we could not find an appropriate OpenMe relationship that contained the same meaning as the endpoint.  Some endpoints could not be supported because we do not support the type of object they work with, such as Movie, Music, or Television objects.  Other endpoints were also services or convenience endpoints that we can achieve the same result with using a combination of the OpenMe relationships. 4.1.3.3 Coverage Table 24 shows the percentage of Foursquare, Facebook, and Twitter endpoints whose functionality can be represented using OpenMe relationships. Both Foursquare and Twitter achieve around an 80% 49 coverage.  Facebook has the highest coverage at around 93%, possibly due to the fact that it structures its API as a graph as well, making the OpenMe relationships more compatible. Our initial goal was not to focus on having OpenMe cover 100% of all OSN functionality.  We instead wanted to cover the majority of functionality, including the most important ones, and then move forward with a feasibility evaluation before ensuring the OpenMe abstractions can cover more of OSN functionality.  This way, a more comprehensive evaluation of the OpenMe relationships is provided. Table 24.  Percentage of OSN specific functionality that is covered by OpenMe.  These endpoint counts do not include endpoints of functionality we have explicitly stated to not support in this version of OpenMe. OSN Number of Endpoints Covered by OpenMe Percentage Foursquare 67 55 82.1% Facebook 123 114 92.7% Twitter 78 62 80.0% Having successfully achieved the initial coverage goal, we believe to have demonstrated the strength and potential of the OpenMe abstractions in terms of using a relationship and graph-based approach.  It also validates our initial set of relationships and the categories they have been organized into.  Future iterations of OpenMe will cover remaining OSN functionality that was not achieved in this iteration without much difficulty due to the structure of the OpenMe relationships. 4.2 Feasibility With an expressiveness evaluation, we have shown how in theory the OpenMe relationships can be used to abstract the functionality of OSNs. We now focus on implementing a number of the relationship to OSN functionality mappings to evaluate the feasibility of our abstractions. This evaluation will determine if the OpenMe abstractions are too high level, meaning it is not possible to implement them in practice, or too low 50 level, meaning we are unable to implement them at the level of abstraction desired. This section focuses on presenting software we have written to implement the OpenMe abstractions and an app that uses this to interface with a variety of OSNs.  Our goal in this section is to use the software to show that we have successfully implemented a number of OpenMe abstractions in real world situations. 4.2.1 Methodology The software implemented to evaluate the feasibility of the OpenMe abstractions with was a web application that exposed the OpenMe relationships as a REST API services.  This web application acts as a middleware platform that sits between apps and OSNs (Figure 14).  This layer acts as a gateway for apps to interface with OSN and proxies calls between an application and connected OSNs to shield the app from the OSNs it is communicating with.  Thus OpenMe does not itself store OSN data or content.  Figure 14:  The OpenMe platform is a piece of middleware that sits between OSNs and apps using it. It provides a number of adapters to map each OSN’s functionalities to the OpenMe relationships. Due to time constraints, only a subset of the OpenMe relationships was implemented in the REST API.  The abstractions we implemented 51 are shown in Table 25.  Our criteria for choosing most of these relationships were to take common ones from the relationship categories defined in Section 3.2.  We chose the is-mutual-with relationship from the roles category, and the posted-photo-on, commented-on, and likes relationship from the content category.  The actions these relationships describe represent some of the most commonly used functionality in OSNs by third party apps [3, 58].  The rest of the relationships were chosen because we consider them to be edge case relationships.  That is, the functionality they describe is not used that often by OSN apps.  These consist of the special has relationship and the wants-to relationship from the desires and deeds category. Table 25.  The OpenMe relationships that were implemented in our feasibility evaluation. OpenMe Relationship Category is-mutual-with Roles posted-photo-on Content commented-on Content likes Content has OSN wants-to Desires and Deeds In order to exercise the relationships we implemented as REST service endpoints, we built a sample proof of concept web application called Instapen.  This application is based on an existing web and iOS application called Instagram16.  Instagram is a simple photo uploading service that is centred on providing a set of interesting and artistic filters to apply to a photo before uploading it.  Our application, Instapen essentially provides similar functionality, but focuses on users uploading photos of hand writing. Instagram also does not run against social networks and stores photos and user data on its own servers.  Since Instapen is an OSN app, we use  16 http://instagr.am 52 the OSNs that are being abstracted by OpenMe to store the uploaded photos and any OSN related data.  Only some application specific data is stored on Instapen.  Lastly, because we have tried to implement in Instapen, most of the functionality that Instagram has, we believe it makes a realistic sample application. 4.2.2 Implementation We now discuss in more detail the implementation of OpenMe and Instapen.  Both applications were written using Java and the Spring Framework17.  Tomcat was used as the web server and MySQL as the database.  The Instapen frontend was implemented in HTML and JavaScript and used the jQuery18 library.  OpenMe had a minimal frontend mostly for testing. 4.2.2.1 OpenMe Architecture  Figure 15.  Diagram showing the different components working with OpenMe. The OpenMe backend is divided into four main components as shown in Figure 15.  The highest-level component is the REST API, which exposes the OpenMe relationships as RESTful endpoints.  Apps will use this  17 http://www.springsource.org 18 http://jquery.com 53 component to interface with OpenMe.  The three other components work together to map OpenMe relationships to OSN specific functionality.  The MySQL database is used for storing any mapping data that needs to be persisted or cached in the OpenMe layer.  Figure 16.  A UML diagram depicting the class and package structure of the OpenMe backend. Figure 16 shows a detailed UML class and package diagram of the four components in OpenMe.  At the top of this figure sits the servlet controllers of the OpenMe backend, which implement the REST API that exposes the OpenMe relationships.  The servlets are organized by 54 relationship category.  Each servlet controller parses and translates an incoming API request and then calls the OpenMe relationship service layer. The relationship service layer also consists of classes organized by relationship category and mimics the structure of the servlet controllers. Each relationship service theoretically implements all the OpenMe relationships under its category, but in our implementation we have only implemented the relationships stated in Table 25.  The ConnectedProviderHelper class is used by each relationship service to abstract what OSNs are available to the app making the API request. This class uses the account components of OpenMe to retrieve this. Thus, each relationship service class is given a list of ProviderRelationships objects to work with, which is an interface. Each OSN supported by OpenMe will have a class that implements the ProviderRelationships interface.  This interface defines every single relationship that OpenMe defines.  The provider will then implement each relationship using the specific functionality of that OSN to conform to the semantics of that relationship.  These provider specific relationship classes then use provider specific object mappers to map OSN specific data objects to abstract OpenMe data objects (Table 27).  This is necessary at this point because the relationship service layer calls the same ProviderRelationships method for each ProviderRelationships object it has in its list and needs to be able to work with objects in the same format as the next step is to merge those objects. Thus, once all data is returned by the provider specific layer, the relationship service layer calls the object mergers shown in the lowest layer of the figure.  These object mergers then execute a complex algorithm to merge objects involved in this API request before returning them to the client app.  The results of object merges are cached in the OpenMe database using the ObjectMappingRepository class.  The merging algorithm is discussed in more detail in the next section. 55 4.2.2.2 Merging OpenMe OSN Objects As mentioned in Figure 16, the OSN provider classes (third package from the top) return all data retrieved from its respective OSN as OpenMe objects to the relationship service classes (second package from the top). At this point the relationship service classes have a list of OpenMe objects for each OSN.  It is possible that certain objects across the lists are actually the same object.  For example, when executing the relationship read_relationship(‘is-mutual-with’, ‘Lauren’, User), each OSN will return a list of users that are mutual with Lauren.  It is possible that within these lists, some users that she is mutual with are actually the same person.  These users also may not have an OpenMe account, nor have been seen by OpenMe before (i.e.:  they have been mapped to the same person previously and that mapping cached by OpenMe). Another example is if a user who has an account on Facebook and Twitter upload the same photo at the same time to both OSNs, OpenMe may consider this the same photo and try to merge them so that the photo is only returned once. Thus, the problem is that these objects need to be checked to see if any of them can be considered the same object.  Then, objects that are the same need to be merged.  OpenMe does this using the ObjectMapper classes (bottom most package).  This object merging is a necessary part of OpenMe and we now present the algorithm in detail. Algorithm Inputs:  A list of lists.  Each list contains OpenMe objects that were translated from OSN specific objects. Output:  A single list of merged OpenMe objects. The algorithm begins by iterating though each OSN’s list.  For each object in the list, we see if it already has an OpenMe ID.  In cases where the object was just created by creating a content relationship such as posted-photo-on, it will have an ID.  If the object has an ID then we 56 persist a mapping of the object’s OpenMe ID to the ID of the object on the OSN it came from (Table 26). Table 26.  An example of an OpenMe to provider object mapping in the OpenMe database. OpenMe ID Provider ID Provider U_234dskfil200 4423666 Facebook After the mapping has been persisted, we check to see if there are any other objects in the other OSN lists with the same OpenMe ID.  If there are, then we add this object in an array of objects to merge later on, keeping track of which object it is to be merged with.  This ends the first conditional branch. The second conditional branch is when the object does not have an OpenMe ID.  In this case we attempt to find it in the mapping database. This is basically checking to see if we have encountered this object before. If there is already a mapping for this object, we retrieve its OpenMe ID and then check to see if there are any other objects in the other OSN lists with the same OpenMe ID, similar to what we did above.  And if there are, we add the object to the array of objects to merge later on. If there is no mapping for this object in the OpenMe database, meaning this is the first time we have seen this object, we create a mapping for it and add it to the list of merged objects.  Figure 17 illustrates this process. map(merged[],	
  osn[],	
  toMerge[])	
   	
  	
  for	
  (object	
  in	
  osn)	
   	
  	
  	
  	
  openMeId	
  =	
  object.getId()	
   	
  	
  	
  	
  if	
  (openMeId	
  !=	
  null)	
   	
  	
  	
  	
  	
  	
  objectMappingRepo.createMapping(object.getPid(),	
   object.getPname())	
   	
   	
  	
  	
  	
  	
  	
  if	
  (merged.contains(openMeId))	
   	
  	
  	
  	
  	
  	
  	
  	
  toMerge.push(object)	
   	
  	
  	
  	
  	
  	
  else	
   	
  	
  	
  	
  	
  	
  	
  	
  merged.push(object)	
   	
  	
  	
  	
  	
  	
  end	
  if	
   	
  	
  	
  	
  else	
   57 	
  	
  	
  	
  	
  	
  openMeId	
  =	
  objectMappingRepo.find(object.getPid(),	
   object.getPname())	
   	
   	
  	
  	
  	
  	
  	
  if	
  (openMeId	
  !=	
  null)	
   	
  	
  	
  	
  	
  	
  	
  	
  if	
  (merged.contains(openMeId))	
   	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  toMerge.push(object)	
   	
  	
  	
  	
  	
  	
  	
  	
  else	
   	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  merged.push(object)	
   	
  	
  	
  	
  	
  	
  	
  	
  end	
  if	
   	
  	
  	
  	
  	
  	
  else	
   	
  	
  	
  	
  	
  	
  	
  	
  objectMappingRepo.createMapping(object.getPid(),	
   object.getPname())	
   	
   	
  	
  	
  	
  	
  	
  	
  	
  merged.push(object)	
   	
  	
  	
  	
  	
  	
  end	
  if	
   	
  	
  	
  	
  end	
  if	
   end	
    Figure 17.  For each object in each of the OSN lists, we determine if it needs to be merged with any objects in the other OSN lists.  In this example we have determined that objects 2-3 and 3-3 need to be merged and are added to the list of objects that need to be merged.  Merging is performed at the end of our algorithm in the merge step. We now have a list of objects to be merged and the rest of the objects, which we call the merged list.  However, there can still exist objects in this list that are from different OSNs and might be considered equal.  Thus, we need to compare every object from an OSN with every other object for all objects in this list.  This is illustrated in Figure 18. Equality comparisons algorithms are implemented per OpenMe object type.  For example, when comparing two OpenMe User objects to determine if they are equal or not, we compare their email addresses. 58  Figure 18.  Comparing all objects in an OSN against all other objects in different OSNs to determine if they can be considered the same object.  In this example, objects 1-1 and 2-2 have been determined equal and thus one of them is added to the list of objects that need to be merged. Once this is done, we are finally ready to merge the objects in the merge list with the rest of the objects.  Recall we have kept track of which objects the objects in the merge list are to be merged with.  Figure 19 illustrates the merge step of our algorithm.  The merging algorithms are also written per OpenMe object type.  But some of the concepts they use are similar.  For example, merging only becomes problematic when there are conflicting properties across the objects to be merged.  Our algorithms resolve this by either using the property that has been most recently updated for the merged object.  Or we use the most common property for the merged object.  Finally, the list of merged objects is returned to the client app that made the request that invoked this process. 59  Figure 19.  The final merge step of our algorithm where all objects are merged.  In this example we see objects 2-3 and 3-2 being merged with 1-1 and object 2-2 being merged with 3-1 as we keep track of which objects each object in the to merge list are to be merged with. 4.2.2.3 Instapen Architecture and Interface The Instapen web application consists of a frontend, and a backend that contains an OpenMe client that wraps the OpenMe REST API to communicate with OpenMe (Figure 20).  Instapen stores some application specific data such as user account information in its own database. Everything else, such as the photos users upload through Instapen are stored on the OSNs it is running against and retrieved when requested. In this initial prototype of Instapen, users sign in using their OpenMe account.  An OpenMe account allows users to connect their OSNs to OpenMe using OAuth [34].  OpenMe itself is then an OAuth provider, which client apps such as Instapen use to allow logging in with OpenMe accounts. 60  Figure 20.  Diagram showing that Instapen communicates with. Figure 21 describes the standard workflow of using OpenMe and Instapen.  A user begins by creating an OpenMe account and connecting his or her OSNs to it (Figure 21a).  The user then signs into Instapen using his or her OpenMe account in Figure 21b.  Figure 21c shows a photo being uploaded where a message describing the photo may be provided as well as a filter.  This photo is posted to all social networks the user has connected to OpenMe.  Instapen’s home screen (Figure 21d) then shows all the photos the user has uploaded.  It retrieves these photos from the OSNs the user has connected as Instapen does not store the photos itself.  Even though the same photo exists on multiple OSNs, Instapen knows that this is the same photo as OpenMe is able to merge equal objects (see Section 4.2.2.2). A user can interact with the photo by clicking on it to access commenting and liking functionality (Figure 21e).  Any comments on this photo from across the OSNs it resides on are merged and shown here. For example, the comment in Figure 21e that says “what pen did you use?” was made by a Facebook user through the Facebook native web interface.  Figure 21e also shows the user who posted the photo replying through the Instapen interface, which uses OpenMe to post the comment on all the OSNs the user has connected (Figure 21f). 61  Figure 21.  Standard workflow for using the Instapen application.  62 4.2.3 Discussion and Results Through our feasibility evaluation, we have shown a successful implementation of a prototype of a service that apps can use to interface with OSNs based on the OpenMe relationships.  These types of services are not easy to achieve and not common.  When implementing the OpenMe prototype, we found that much focus was on its backend structure and the merging algorithm.  Putting our focus on this and creating a well-designed backend system will make it easier to implement additional OpenMe relationships and better merging object techniques in the future.  For this current iteration, we have already implemented a few relationships and successfully built Instapen to use them.  Additionally, Instapen being based on a real world application, further demonstrates the feasibility of our abstractions. 4.3 Summary In this chapter, two evaluations where done on the OpenMe abstractions. The first was an expressiveness evaluation to determine the amount of OSN functionality the OpenMe relationships are able to express.  This was done by inspecting each method in an OSN’s API and writing the equivalent functionality of the API call using an OpenMe relationship. We achieved our goal to cover at least 80% of functionality for the OSNs Foursquare, Facebook, and Twitter, focussing on the most important functionality apps would use.  This is sufficient for a first iteration of OpenMe as we also wanted to focus on implementing a number of these relationships in order to evaluate their feasibility.  Future iterations of OpenMe will extend the relationships to cover the remaining OSN functionality. The feasibility evaluation was done to determine if it is possible to implement the OpenMe abstractions that have been developed.  We successfully prototyped a middleware service that exposed the OpenMe relationships as a REST API and wrote a sample application called 63 Instapen based on the commercial application Instagram to exercise the REST endpoints in a realistic way.  We were able to implement the REST API to realize the OpenMe relationships successfully at the abstraction level desired, indicating that they are not too high level, nor too low level.   64 Chapter 5 Conclusion In this thesis, we have motivated the need for a set of OSN abstractions that apps running against multiple OSNs can use to interface with the OSNs.  We have built a common OSN model that achieves this called OpenMe.  OpenMe abstracts OSN functionality in a novel manner by focussing on the interactions objects can have with other objects in an OSN.  With this structure, we were able to use OpenMe to represent at least 80% of the functionality available in Foursquare, Facebook, and Twitter, displaying significant expressiveness for a first version.  A prototype was also successfully developed to prove the feasibility of implementing the OpenMe relationships in a service that could be used by apps in a real world setting. In this concluding chapter, we revisit the main contributions of our work and discuss future work that can be done to enhance or extend OpenMe. 5.1 Contribution Summary When describing the goals for the OpenMe abstractions, we defined three criteria that our abstractions needed to have.  It is the existence of all three of these criteria in a single set of abstractions that make OpenMe a novel contribution.  Reviews of similar works (Section 2) have shown that no single related work has met all three of these criteria.  Here, we reiterate those criteria and summarize if our research goals for the OpenMe abstractions have been met. 65 5.1.1 Abstract Existing OSNs Our first goal for OpenMe is that it needs to be able to abstract existing OSNs.  This means that it should be able to be used with today’s OSNs and not require provider side changes or implementations (such as a standard would).  Thus, OpenMe takes care of all logic in abstracting OSN providers and making them work together.  Furthermore, OSNs do not need to know that OpenMe is using them.  Through initial expressiveness and feasibility evaluations with the three popular OSNs Foursquare, Twitter, and Facebook, we have demonstrated that it is able to abstract all three with little problems.  We also do not foresee any problems with supporting more existing OSNs with OpenMe. 5.1.2 Black Box Behaviour The second goal of OpenMe is that it needs to behave like a black box for apps using it to communicate with OSNs.  Apps interfacing with OpenMe should not need to know what OSNs OpenMe is abstracting.  In terms of an API, this means that (1) endpoints exposed by OpenMe for apps should not only work for specific OSNs.  And (2), apps making calls to the API should not be required to specify the OSNs they are targeting. Our feasibility evaluation involved the creation of an OpenMe API built on the OpenMe relationship abstractions.  We were able to implement this API and satisfy both constraints, demonstrating that our OpenMe relationships are sufficiently high level, and can behave like a black box. 5.1.3 Future Proof It is not enough for a set of OSN abstractions to work with only existing OSNs.  With the growing number of OSNs each year, the third goal of OpenMe is that its abstraction structure would be able to support future OSNs as well.  We have described how OpenMe focuses on abstracting verbs or actions objects can make on other objects in social networks instead of abstracting the objects themselves.  Referring to these as 66 relationships, we have seen from our initial evaluations that there are a limited number of these relationships, at least far less than the number of different objects that can exist in social networks.  Thus, we foresee that future OSNs may contain objects we have not seen before, but similar relationships between those objects to the ones we have defined in OpenMe. 5.2 Future Work During the construction of the OpenMe OSN abstractions, there were a number of areas that we omitted due to time constraints.  There were also a number of challenges that we faced and only provided initial solutions for.  This section discusses what future work can be done to evolve OpenMe and what work can be done to improve upon the current version. 5.2.1 Evolving OpenMe 5.2.1.1 Evaluation Perhaps one of the most important future tasks is to perform more evaluation on OpenMe.  We have performed expressiveness and feasibility evaluations, which have shown promising results.  But other common metrics to evaluate abstractions on such as readability and reasoning/inference also need to be performed.  A large part of these evaluations are HCI related and involve user studies.  Taking this further, studying developers using OpenMe relationships in real world situations can also be an important method to evaluate our abstractions.  Finally, performance tests need to be done to determine the overhead of the OpenMe system that we implemented.  We need to determine the scale in terms of number of clients that OpenMe can support and what difficulties arise and at what threshold.  Performance tests will further validate (or invalidate) the feasibility of such a system. 67 5.2.1.2 OpenMe OAuth Proxy As discussed in Section 4.2.2.3, for our initial proof of concept prototypes, we have implemented an OSN account manager on our OpenMe system. In doing so, OpenMe uses one API key per OSN it supports and proxies all client app calls using that key.  This will not work in practice since each key is subject to query per second (QPS) and max number of query limits enforced by every OSN.  It is also impractical to force users to create yet another account (an OpenMe account), just to use apps written on the OpenMe platform.  Instead, it would be better if apps allowed users to sign in to them using any OSN OpenMe supports, and have OpenMe proxy the OAuth process between the app and the OSNs, similar to what Gigya does.  This way, each app will need its own API key for the OSNs and users need not create yet another account. 5.2.2 Improving OpenMe 5.2.2.1 Support more OSNs In our initial evaluations of OpenMe, we only supported the social networks Foursquare, Facebook, and Twitter.  Clearly an abstraction platform such as OpenMe needs to support a larger variety of OSNs. Supporting more OSNs involves implementing more provider relationship classes in our system (Section 4.2.2.1).  A new class needs to be implemented per new OSN to be supported.  Our system architecture makes it fairly straightforward to test new OSNs against OpenMe. 5.2.2.2 Improve Merging Algorithms The current OpenMe object merging algorithm described in Section 4.2.2.2 is fairly complex and only an initial attempt to solve the merging problem.  Portions of this algorithm can be improved, especially the object equality and merge functions.  We currently implement very basic functions to determine if two objects are equal and to merge objects. 68 Further investigation can be done to see if other points of data can be used in these tasks instead of just the object properties like we are limiting ourselves to in our initial methods. 5.3 Concluding Remarks We foresee the need for OSN abstraction layers to be more prevalent as the popularity of OSNs continues to rise.  Additionally, as we move into a more social era for the web, we are seeing more and more OSNs competing for users.  With the average user’s friend group inevitably split between multiple social networks, users will need more structured tools to help them manage these networks. The OpenMe relationships presented in this thesis are a first step towards helping app developers build these tools for end users.  We have shown that these relationships are highly expressive and have successfully developed a proof of concept system and an app that uses this in a real world setting.  This achieves our goals of building an abstraction layer that apps can use to interface with a variety of OSNs. The work done in this thesis shows promise for the novel method of building OSN abstractions that focus on relationships between objects rather than the objects themselves.  We believe this work will help shape how OSNs are viewed at a high level and act as a reference point or be used by future abstraction layers and OSN APIs.   69    Bibliography [1] N. N. Ali and H. Mansoor, “Cross Platform Mobile Application Development Framework.” [2] J. Arendt and S. J. Graves, “Virtual question changes: reference in evolving environments,” Reference Services Review, vol. 39, no. 2, pp. 187-205, 2011. [3] F. Benevenuto, T. Rodrigues, and M. Cha, “Characterizing User Behavior in Online Social Networks,” Proceedings of the 9th, pp. 49- 62, 2009. [4] U. Bojārs, J. G. Breslin, a. Finn, and S. Decker, “Using the Semantic Web for linking and reusing data across Web 2.0 communities,” Web Semantics: Science, Services and Agents on the World Wide Web, vol. 6, no. 1, pp. 21-28, Feb. 2008. [5] J. Bonneau, J. Anderson, and G. Danezis, “Prying Data out of a Social Network,” 2009 International Conference on Advances in Social Network Analysis and Mining, pp. 249-254, Jul. 2009. [6] D. M. Boyd and N. B. Ellison, “Social Network Sites: Definition, History, and Scholarship,” Journal of Computer-Mediated Communication, vol. 13, no. 1. pp. 210-230, 17-Oct-2007. [7] J. G. Breslin, A. Passant, and S. Decker, “The Social Semantic Web,” The Social Semantic Web, 2009. [8] M. Bulut and Y. Yilmaz, “Crowdsourcing location-based queries,” Pervasive Computing and, pp. 513-518, 2011. [9] J. Burgos, “Semantic Web Standards.” [10] M. Burke and C. Marlow, “Feed me: motivating newcomer contribution in social network sites,” of the 27th international conference on, 2009. 70 [11] K. Cahill, “Building a virtual branch at Vancouver Public Library using Web 2.0 tools,” Program: electronic library and information systems, vol. 43, no. 2, pp. 140-155, 2009. [12] C. Carter, A. El Rhalibi, M. Merabti, and M. Price, “Homura and Net-Homura: The creation and web-based deployment of cross- platform 3D games,” in Ultra Modern Telecommunications & Workshops, 2009. ICUMT’09. International Conference on, 2009, pp. 1–8. [13] P. Chiu and C. Cheung, “Online Social Networks  : Why Do ‘ We ’ Use Facebook  ?,” The open knowledge society. A, pp. 67-74, 2008. [14] R. K. Commercenet, “Microformats The Next (Small) Thing on the Semantic Web?,” Ieee Internet Computing, no. February, pp. 68-75, 2006. [15] O. Corcho, “Evaluating knowledge representation and reasoning capabilities of ontology specification languages,” Evaluation, 2000. [16] C. Cuddy and N. R. Glassman, “Location-Based Services: Foursquare and Gowalla, Should Libraries Play?,” Journal of Electronic Resources in Medical Libraries, vol. 7, no. 4, pp. 336-343, Dec. 2010. [17] L. Ding, L. Zhou, and T. Finin, “How the semantic web is being used: An analysis of foaf documents,” System Sciences, 2005., vol. 0, no. C, pp. 1-10, 2005. [18] N. B. Ellison, C. Steinfield, and C. Lampe, “The Benefits of Facebook ‘Friends:’ Social Capital and College Students’ Use of Online Social Network Sites,” Journal of Computer-Mediated Communication, vol. 12, no. 4, pp. 1143-1168, Jul. 2007. [19] D. Florencio, “A large-scale study of web password habits,” international conference on World Wide Web, pp. 657-665, 2007. [20] S. Gaw and E. W. Felten, “Password management strategies for online accounts,” Proceedings of the second symposium on Usable privacy and security - SOUPS  ’06, p. 44, 2006. 71 [21] J. Goecks, “Leveraging social networks for information sharing,” Proceedings of the 2004 ACM conference on, pp. 328-331, 2004. [22] J. Golbeck, “Linking social networks on the web with foaf: A semantic web case study,” Proceedings of the 23rd national conference on, pp. 1138-1143, 2008. [23] J. F. González, M. C. Rodríguez, M. L. Nistal, and L. A. Rifón, “Reverse OAuth: A solution to achieve delegated authorizations in single sign-on e-learning systems,” Computers & Security, vol. 28, no. 8, pp. 843-856, Nov. 2009. [24] L. Guo, E. Tan, S. Chen, and X. Zhang, “Analyzing patterns of user content generation in online social networks,” Proceedings of the 15th, pp. 369-377, 2009. [25] Z. Guo, R. Singh, and M. Pierce, “Building the PolarGrid portal using web 2.0 and OpenSocial,” Proceedings of the 5th Grid Computing Environments Workshop on - GCE  ’09, p. 1, 2009. [26] I. Guy, M. Jacovi, E. Shahar, N. Meshulam, V. Soroka, and S. Farrell, “Harvesting with SONAR: the value of aggregating social network information,” in Proceeding of the twenty-sixth annual SIGCHI conference on Human factors in computing systems, 2008, pp. 1017–1026. [27] A. Harris and S. Lessick, “Libraries Get Personal: Facebook Applications, Google Gadgets, and MySpace Profiles,” Library Hi Tech News, vol. 24, no. 8, pp. 30-32, 2007. [28] M. Häsel, “Opensocial: An Enabler for Social Applications on the Web,” Communications of the ACM, vol. 54, no. 1, p. 139, Jan. 2011. [29] J. Heer, “Vizster: Visualizing online social networks,” Visualization, 2005. INFOVIS 2005. IEEE, 2005. [30] S. Hosio, H. Kukka, and J. Riekki, “Leveraging social networking services to encourage interaction in public spaces,” in Proceedings of the 7th international Conference on Mobile and Ubiquitous Multimedia, 2008, pp. 2–7. 72 [31] A. Iriberri and G. Leroy, “A life-cycle perspective on online community success,” ACM Computing Surveys, vol. 41, no. 2, pp. 1- 29, Feb. 2009. [32] P. Jain, T. Rodrigues, G. Magno, P. Kumaraguru, and V. Almeida, “Cross-Pollination of Information in Online Social Media: A Case Study on Popular Social Networks,” 2011 IEEE Third Int’l Conference on Privacy, Security, Risk and Trust and 2011 IEEE Third Int'l Conference on Social Computing, pp. 477-482, Oct. 2011. [33] D. B. Jr, “Crud matrices for detailed object oriented design,” Journal of Computing Sciences in Colleges, pp. 306-322, 2002. [34] P. Kaila, “OAuth and OpenID 2.0,” Seminar on Network Security, pp. 18-22, 2008. [35] S. Kaltofen, M. Milrad, and A. Kurti, “A cross-platform software system to create and deploy mobile mashups,” Web Engineering, pp. 518–521, 2010. [36] R. Khare, “Microformats: a pragmatic path to the semantic web,” the 15th international conference on World Wide Web, pp. 865-866, 2006. [37] M. N. Ko, G. P. Cheek, M. Shehab, and R. Sandhu, “Social- Networks Connect Services,” Computer, vol. 43, no. 8, pp. 37-43, Aug. 2010. [38] W. Kongdenfha, B. Benatallah, and J, “Rapid development of spreadsheet-based web mashups,” on World wide web, pp. 851-860, 2009. [39] S. Lewis et al., “If SWORD is the answer, what is the question?: Use of the Simple Web-service Offering Repository Deposit protocol,” Program: electronic library and information systems, vol. 43, no. 4, pp. 407-418, 2009. [40] J. Lindqvist, J. Cranshaw, J. Wiese, and J. Hong, “I’m the mayor of my house: examining why people use foursquare-a social-driven location sharing application,” Proceedings of the, pp. 2409-2418, 2011. 73 [41] I. Lindt, J. Ohlenburg, U. Pankoke-Babatz, S. Ghellal, L. Oppermann, and M. Adams, “Designing cross media games,” in Pervasive’05, 2005. [42] S. Livingstone, “Taking risky opportunities in youthful content creation: teenagers’ use of social networking sites for intimacy, privacy and self-expression,” New Media & Society, vol. 10, no. 3, pp. 393-411, Jun. 2008. [43] L. Lockyer and J. Patterson, “Integrating Social Networking Technologies in Education:  A Case Study of a Formal Learning Environment,” 2008 Eighth IEEE International Conference on Advanced Learning Technologies, no. July, pp. 529-533, 2008. [44] E. M. Maximilien, A. Ranabahu, and K. Gomadam, “An online platform for web apis and service mashups,” Internet Computing, IEEE, vol. 12, no. 5, pp. 32–43, 2008. [45] F. McCown, “What happens when facebook is gone?,” Proceedings of the 9th ACM/IEEE-CS joint, pp. 251-254, 2009. [46] S. a. McIlraith and T. C. Son, “Semantic Web services,” IEEE Intelligent Systems, vol. 16, no. 2, pp. 46-53, Mar. 2001. [47] S. Michalakos, “G2G: location-aware mobile social networking with applications in recommender systems and gaming,” Conference on Advances in Mobile, pp. 163-169, 2008. [48] E. Miluzzo, N. Lane, and S. Eisenman, “CenceMe – Injecting Sensing Presence into Social Networking Applications,” Smart Sensing and Context, pp. 1-28, 2007. [49] M. Morris and J. Teevan, “What do people ask their social networks, and why? A survey study of status message Q&A behavior,” Proceedings of the 28th international, pp. 1739-1748, 2010. [50] M. Mostarda, D. Palmisano, and F. Zani, “Towards an OpenID- based solution to the Social Network Interoperability problem,” on the Future of Social, 2009. 74 [51] M. Motoyama and G. Varghese, “Crosstalk: scalably interconnecting instant messaging networks,” in Proceedings of the 2nd ACM workshop on Online social networks, 2009, pp. 61–68. [52] A. Nadamoto, E. Aramaki, and T. Abekawa, “Extracting the gist of social network services using Wikipedia,” Applications & Services, 2010. [53] A. Nazir and S. Raza, “Unveiling facebook: a measurement study of social network based applications,” conference on Internet measurement, pp. 43-56, 2008. [54] M. E. J. Newman, D. J. Watts, and S. H. Strogatz, “Random graph models of social networks.,” Proceedings of the National Academy of Sciences of the United States of America, vol. 99 Suppl 1, pp. 2566- 72, Feb. 2002. [55] T. Paek, M. Gamon, S. Counts, and D. Chickering, “Predicting the importance of newsfeed posts and social network friends,” Proc. AAAI, pp. 1419-1424, 2010. [56] D. Recordon, “OpenID 2.0: a platform for user-centric identity management,” ACM workshop on Digital identity management, pp. 11-15, 2006. [57] M. Rowe, “The credibility of digital identity information on the social web: a user study,” in Proceedings of the 4th workshop on Information credibility, 2010, pp. 35–42. [58] F. Schneider, A. Feldmann, and B. Krishnamurthy, “Understanding online social network usage from a network perspective,” Proceedings of the 9th, 2009. [59] V. Seppa, “The Future of Social Networking,” Seminar on Internetworking, 2008. [60] M. Skeels, “When social networks cross boundaries: a case study of workplace use of facebook and linkedin,” Proceedings of the ACM 2009 international, pp. 95-103, 2009. 75 [61] M. Subramani, “Knowledge-sharing and influence in online social networks via viral marketing,” Communications of the ACM, vol. 46, no. 12, pp. 300-307, 2003. [62] A. Tapiador, A. Fumero, and J. Salvachúa, “Extended identity for social networks,” Recent Trends and Developments in Social Software, pp. 162–168, 2011. [63] M. Torkjazi, R. Rejaie, P. A. Building, and F. Park, “Hot Today , Gone Tomorrow  : On the Migration of MySpace Users,” WOSN’09, pp. 43-48, 2009. [64] R. S. Weisskirch, “Parenting by cell phone: parental monitoring of adolescents and family relations.,” Journal of youth and adolescence, vol. 38, no. 8, pp. 1123-39, Sep. 2009. [65] A. West, J. Lewis, and P. Currie, “Students’ Facebook ‘friends’: public and private spheres,” Journal of Youth Studies, vol. 12, no. 6, pp. 615-627, Dec. 2009. [66] Q. Wu, “Modeling and implementing collaborative editing systems with transactional techniques,” Collaborative Computing: Networking,, 2010. [67] C. A. Yeung, I. Liccardi, K. Lu, O. Seneviratne, and T. Berners-Lee, “Decentralization: The future of online social networking,” in W3C Workshop on the Future of Social Networking Position Papers, 2009, vol. 2.   76 Appendix A OpenMe OSN Object Abstractions OpenMe defines a set of objects that are used as subjects and predicate objects in the OpenMe relationships.  Some objects will abstract multiple OSN specific objects across OSNs, but the majority of the OpenMe objects will mean the same thing across OSNs.  In the first iteration of OpenMe, we have defined the following objects to supplement the initial relationships we have defined to reach our coverage goal (see Section 4.1.3.3.  However, more OpenMe objects can be defined in future iterations easily within the OpenMe relationship abstraction model.  OSN User Place Post Collection Photo Video Group Event Comment Message Document  These objects map down to the objects in Foursquare, Facebook, and Twitter as shown in Table 27.  77 Table 27:  OpenMe abstract object mappings to Foursquare, Facebook, and Twitter. OpenMe object Foursquare Facebook Twitter OSN Foursquare Facebook Twitter User User User User Location Checkin Checkin Geo Place Venue Page (that has location) Place Collection List Album List Post Tip Post Tweet Url N/A Link Tweet Photo Photo Photo Image Video N/A Video N/A Group N/A Group List Event Event Event N/A Comment Comment Comment Tweet Message N/A Message Message (not supported in OpenMe) N/A Page N/A Document N/A Document N/A (not an object in OpenMe, supported through relationships) Relationship Relationship Relationship (not an object in OpenMe, supported through relationships) N/A FriendList List (not an object in OpenMe, supported through relationships) FriendRequest FriendRequest FriendRequest   78 Appendix B Expressiveness Evaluation This appendix contains an exhaustive mapping of the OpenMe relationships to the API calls that they support in each OSN. B.1 Roles Table 28.  OSN specific functionality that OpenMe role relationships can abstract. OpenMe relationship Usage API Method OSN knows d(‘knows’, {USER_ID}, {USER_ID_TO_REMOVE}, label={LIST_NAME}) POST /lists/members/destroy TW DELETE /FRIENDLIST_ID/members/USER_I D FB r(‘knows’, User, {USER_ID}) GET /lists/memberships TW r(‘knows’, {USER_ID}, {USER_ID_TO_CHECK}, label={LIST_NAME}) GET /lists/members/show TW r(‘knows’, {USER_ID}, User, label={LIST_NAME}) GET /lists/members TW GET /lists/show TW GET /FRIENDLIST_ID/members FB c(‘knows’, {USER_ID}, {USER_ID_TO_ADD}, label={LIST_NAME}) POST /lists/members/create TW POST /FRIENDLIST_ID/members/USER_I D FB d(‘knows’, {USER_ID}, User, label={LIST_NAME}) POST /lists/destroy TW u(‘knows’, {USER_ID}, User, label={LIST_NAME}, ...) POST /lists/update TW r(‘knows’, {USER_ID}, User, label={KNOWS_LABEL}) GET /FRIENDLIST_ID FB 79 OpenMe relationship Usage API Method OSN r(‘knows’, {USER_ID}, User) GET /lists TW GET /USER_ID/friendlists FB is-mutual- with r(‘is-mutual-with’, {USER_ID}, User) GET /users/USER_ID/friends FS GET /USER_ID/friends FB c(‘is-mutual-with’, {USER_ID}, {USER_ID_TO_APPROVE}) POST /users/USER_ID_TO_APPROVE/app rove FS d(‘is-mutual-with’, {USER_ID}, {USER_ID_TO_APPROVE}) POST /users/USER_ID_TO_APPROVE/den y FS c(‘is-mutual-with’, {USER_ID}, {USER_ID_TO_REQUEST}) POST /users/USER_ID_TO_REQUEST/req uest FS d(‘is-mutual-with’, {USER_ID}, {USER_ID_TO_UNFRIEND}) POST /users/USER_ID/unfriend FS r(‘is-mutual-with’, {USER_ID}, {USER_ID}) GET /friendships/exists TW GET /friendships/show TW GET /PROFILE_ID/friends/FRIEND_ID FB blocked r(‘blocked’, {USER_ID}, User) GET /blocks/blocking TW GET /blocks/blocking/ids TW r(‘blocked’, {USER_ID}, {USER_ID}) GET /blocks/exists TW c(‘blocked’, {USER_ID}, {USER_ID}) POST /blocks/create TW d(‘blocked’, {USER_ID}, {USER_ID}) POST /blocks/destroy TW is-part-of r(‘is-part-of’, {USER_ID}, Place, label=’mayor’) GET /users/USER_ID/mayorships FS r(‘is-part-of’, User, {EVENT_ID}) GET /EVENT_ID/invited FB r(‘is-part-of’, {USER_ID}, {EVENT_ID}) GET /EVENT_ID/invited/USER_ID FB c(‘is-part-of’, {USER_ID}, {EVENT_ID}) POST /EVENT_ID/invited/USER_ID FB d(‘is-part-of’, {USER_ID}, {EVENT_ID}) DELETE /EVENT_ID/invited/USER_ID FB 80 OpenMe relationship Usage API Method OSN r(‘is-part-of’, User, {GROUP_ID}) GET /GROUP_ID/members FB r(‘is-part-of’, {USER_ID}, Group) GET /USER_ID/groups FB manages r(‘manages’, {USER_ID}, Place) GET /venues/managed FS follows c(‘follows’, {USER_ID}, {USER_ID_TO_FOLLOW}) POST /users/USER_ID_TO_FOLLOW/requ est FS POST /friendships/create TW r(‘follows’, User, {COLLECTION_ID}) GET /lists/LIST_ID/followers FS GET /lists/subscribers TW c(‘follows’, {USER_ID}, {COLLECTION_ID}) POST /lists/LIST_ID/follow FS POST /lists/subscribers/create TW d(‘follows’, {USER_ID}, {COLLECTION_ID}) POST /lists/LIST_ID/unfollow FS POST /lists/subscribers/destroy TW r(‘follows’, User, {USER_ID}) GET /followers/ids TW GET /USER_ID/subscribers FB r(‘follows’, {USER_ID}, User) GET /friends/ids TW GET /USER_ID/subscribedto FB d(‘follows’, {USER_ID}, {USER_ID_TO_UNFOLLOW}) POST /friendships/destroy TW r(‘follows’, {USER_ID}, Collection) GET /lists/all TW r(‘follows’, {USER_ID}, {COLLECTION_ID}) GET /lists/subscribers/show TW r(‘follows’, {USER_ID}, Collection, Collection.creator!={USER_ ID}) GET /lists/subscriptions TW is-family r(‘is-family’, {USER_ID}, User) GET /USER_ID/family FB 81 B.2 Content Table 29.  OSN specific functionality that OpenMe content relationships can abstract. OpenMe relationship Usage API Method OSN posted-on r(‘posted-on’, User, {PLACE_ID}) GET /venues/VENUE_ID/tips FS r(‘posted-on’, User, Place, Post.id={POST_ID}) GET /tips/TIP_ID FS c(‘posted-on’, {USER_ID}, {PLACE_ID}, Post.text={POST_TEXT}, ...) POST /tips/add FS d(‘posted-on’, {USER_ID}, {PLACE_ID}, Post.id={POST_ID}) POST /lists/LIST_ID/updateitem FS r(‘posted-on’, User, User) GET /statuses/public_timeline TW r(‘posted-on’, User, {USER_ID}) GET /USER_ID/feed FB GET /statuses/user_timeline TW GET /statuses/home_timeline TW r(‘posted-on’, {USER_ID}, {USER_ID}, Post.id={POST_ID}) GET /statuses/show/:id TW GET /STATUS_ID FB d(‘posted-on’, {USER_ID}, {USER_ID}, Post.id={POST_ID}) POST /statuses/destroy/:id TW c(‘posted-on’, {USER_ID}, {USER_ID}, Post.text={POST_TEXT}, ...) POST /statuses/update TW POST /PROFILE_ID/feed FB c(‘posted-on’, {USER_ID}, {EVENT_ID}, Post.text={POST_TEXT}, ...) POST /EVENT_ID/feed FB c(‘posted-on’, {USER_ID}, {GROUP_ID}, Post.text={POST_TEXT}, ...) POST /GROUP_ID/feed FB r(‘posted-on’, User, Object, Post.id={POST_ID}) GET /POST_ID FB d(‘posted-on’, User, Object, Post.id={POST_ID}) DELETE /POST_ID FB r(‘posted-on’, {USER_ID}, Object) GET /USER_ID/posts FB 82 OpenMe relationship Usage API Method OSN r(‘posted-on’, {USER_ID}, {USER_ID}) GET /USER_ID/statuses FB posted- photo-on r(‘posted-photo-on’, {USER_ID}, Object) GET /users/USER_ID/photos FS r(‘posted-photo-on’, User, {PLACE_ID}) GET /venues/VENUE_ID/photos FS c(‘posted-photo-on’, {USER_ID}, {PLACE_ID}, Photo.name={NAME}, Photo.data=byte[], ...) POST /lists/LIST_ID/updateitem FS d(‘posted-photo-on’, {USER_ID}, {PLACE_ID}, Photo.id={PHOTO_ID}) POST /lists/LIST_ID/updateitem FS r(‘posted-photo-on’, User, Object, Photo.id={PHOTO_ID}) GET /photos/PHOTO_ID FS GET /PHOTO_ID FB c(‘posted-photo-on’, {USER_ID}, {LOCATION_ID}, Photo.name={NAME}, Photo.data=byte[], ...) POST /photos/add FS c(‘posted-photo-on’, {USER_ID}, {USER_ID}, Photo.desc={DESC}, Photo.data=byte[], ...) POST /statuses/update_with_media TW POST /PROFILE_ID/photos FB r(‘posted-photo-on’, {USER_ID}, {COLLECTION_ID}) GET /ALBUM_ID/photos FB c(‘posted-photo-on’, {USER_ID}, {COLLECTION_ID}, Photo.data={byte[]}, Photo.desc={DESC}, ...) POST /ALBUM_ID/photos FB r(‘posted-photo-on’, User, {EVENT_ID}) GET /EVENT_ID/photos FB c(‘posted-photo-on’, {USER_ID}, {EVENT_ID}, Photo.name={PHOTO_NAME}, Photo.data={BYTE[]}, ...) POST /EVENT_ID/photos FB posted-url-on c(‘posted-url-on’, {USER_ID}, {EVENT_ID}, Url.url={URL}, ...) POST /EVENT_ID/feed FB c(‘posted-url-on’, {USER_ID}, {GROUP_ID}, Url.url={URL}, ...) POST /GROUP_ID/feed FB 83 OpenMe relationship Usage API Method OSN r(‘posted-url-on’, User, User, Url.id={URL_ID}) GET /LINK_ID FB r(‘posted-url-on’, {USER_ID}, Object) GET /USER_ID/links FB c(‘posted-url-on’, {USER_ID}, {USER_ID}, Url.url={URL}, ...) POST /PROFILE_ID/links FB likes r(‘likes’, User, {COLLECTION_ID}) GET /ALBUM_ID/likes FB c(‘likes’, {USER_ID}, {COLLECTION_ID}) POST /ALBUM_ID/likes FB d(‘likes’, {USER_ID}, {COLLECTION_ID}) DELETE /ALBUM_ID/likes FB r(‘likes’, User, {LOCATION_ID}) GET /CHECKIN_ID/likes FB c(‘likes’, {USER_ID},{LOCATION_ID}) POST /CHECKIN_ID/likes FB d(‘likes’, {USER_ID}, {LOCATION _ID}) DELETE /CHECKIN_ID/likes FB r(‘likes’, User, {COMMENT_ID}) GET /COMMENT_ID/likes FB c(‘likes’, {USER_ID},{COMMENT_ID}) POST /COMMENT_ID/likes FB d(‘likes’, {USER_ID}, {COMMENT_ID}) DELETE /COMMENT_ID/likes FB r(‘likes’, User, {LINK_ID}) GET /LINK_ID/likes FB r(‘likes’, User, {PHOTO_ID}) GET /PHOTO_ID/likes FB c(‘likes’, {USER_ID},{PHOTO_ID}) POST /PHOTO_ID/likes FB d(‘likes’, {USER_ID}, {PHOTO_ID}) DELETE /PHOTO_ID/likes FB r(‘likes’, User, {POST_ID}) GET /POST_ID/likes FB GET /STATUS_ID/likes FB POST /statuses/retweet/:id TW c(‘likes’, {USER_ID},{POST_ID}) POST /POST_ID/likes FB POST /STATUS_MESSAGE_ID/likes FB d(‘likes’, {USER_ID}, DELETE /POST_ID/likes FB 84 OpenMe relationship Usage API Method OSN {POST_ID}) DELETE /STATUS_MESSAGE_ID/likes FB r(‘likes’, User, {VIDEO_ID}) GET /VIDEO_ID/likes FB c(‘likes’, {USER_ID},{VIDEO_ID}) POST /VIDEO_ID/likes FB d(‘likes’, {USER_ID}, {VIDEO_ID}) DELETE /VIDEO_ID/likes FB r(‘likes’, {USER_ID}, Object) GET /USER_ID/likes FB commented- on c(‘commented-on’, {USER_ID}, {LOCATION_ID}, Comment.message={MESSAGE}) POST /checkins/CHECKIN_ID/addcom ment FS POST /CHECKIN_ID/comments FB d(‘commented-on’, {USER_ID}, {LOCATION_ID}, Comment.id={COMMENT_ID}) POST /checkins/CHECKIN_ID/delete comment FS r(‘commented-on’, User, {COLLECTION_ID}) GET /ALBUM_ID/comments FB c(‘commented-on’, {USER_ID}, {COLLECTION_ID}, Comment.text={COMMENT_TEXT}, ...) POST /ALBUM_ID/comments FB r(‘commented-on’, User, {LOCATION_ID}) GET /CHECKIN_ID/comments FB d(‘commented-on’, {USER_ID}, Post, Comment.id={COMMENT_ID}) DELETE /COMMENT_ID FB r(‘commented-on’, User, {URL_ID}) GET /LINK_ID/comments FB c(‘commented-on’, {USER_ID}, {URL_ID}, Comment.text={COMMENT_TEXT}, ...) POST /LINK_ID/comments FB r(‘commented-on’, User, {PHOTO_ID}) GET /PHOTO_ID/comments FB c(‘commented-on’, {USER_ID}, {PHOTO_ID}, Comment.text={COMMENT_TEXT}, ...) POST /PHOTO_ID/comments FB r(‘commented-on’, User, {POST_ID}) GET /POST_ID/comments FB GET FB 85 OpenMe relationship Usage API Method OSN /STATUS_MESSAGE_ID/comments c(‘commented-on’, {USER_ID}, {POST_ID}, Comment.text={COMMENT_TEXT}, ...) POST /POST_ID/comments FB POST /STATUS_MESSAGE_ID/comments FB POST /statuses/update TW r(‘commented-on’, User, {VIDEO_ID}) GET /VIDEO_ID/comments FB c(‘commented-on’, {USER_ID}, {VIDEO_ID}, Comment.text={COMMENT_TEXT}, ...) POST /VIDEO_ID/comments FB posted-video- on r(‘posted-video-on’, User, {EVENT_ID}) GET /EVENT_ID/videos FB c(‘posted-video-on’, {USER_ID}, {EVENT_ID}, Video.name={VIDEO_NAME}, Video.data={BYTE[]}, ...) POST /EVENT_ID/videos FB r(‘posted-video-on’, User, Object, Video.id={VIDEO_ID}) GET /VIDEO_ID FB c(‘posted-video-on’, {USER_ID}, {USER_ID}, Video.name={VIDEO_NAME}, Video.data={BYTE[]}, ...) POST /PROFILE_ID/videos FB shared-on c(‘shared-on’, {USER_ID}, {USER_ID}, Collection.id={COLLECTION_ID }, osns=’facebook,twitter’) POST /lists/LIST_ID/share FS r(‘shared-on’, {USER_ID}, {USER_ID}) GET /statuses/retweeted_by_me TW GET /statuses/retweeted_by_user TW r(‘shared-on’, User, {USER_ID}) GET /statuses/retweeted_to_me TW GET /statuses/retweeted_to_user TW r(‘shared-on’, User, User, Post.author={USER_ID}) GET /statuses/retweets_of_me TW r(‘shared-on’, User, User, Post.id={POST_ID}) GET /statuses/:id/retweeted_by TW GET /statuses/:id/retweeted_by/ TW 86 OpenMe relationship Usage API Method OSN ids GET /statuses/retweets/:id TW c(‘shared-on’, {USER_ID}, {USER_ID}, Post.id={POST_ID}) POST /statuses/retweet/:id TW is-in- newsfeed-of r(‘is-in-newsfeed-of’, Post, {USER_ID}) GET /statuses/home_timeline TW GET /statuses/user_timeline TW GET /USER_ID/home FB r(‘is-in-newsfeed-of’, Post, {EVENT_ID}) GET /EVENT_ID/feed FB r(‘is-in-newsfeed-of’, Post, {GROUP_ID}) GET /GROUP_ID/feed FB r(‘is-in-newsfeed-of’, Post, {USER_ID}, feedName={FEED_NAME}) GET /lists/statuses TW is-tagged-in r(‘is-tagged-in’, {USER_ID}, Post) GET /statuses/mentions TW GET /USER_ID/tagged FB r(‘is-tagged-in’, User, {PHOTO_ID}) GET /PHOTO_ID/tags FB c(‘is-tagged-in’, {USER_ID}, {PHOTO_ID}, x={X}, y={Y}) POST /PHOTO_ID/tags/USER_ID FB u(‘is-tagged-in’, {USER_ID}, {PHOTO_ID}, x={X}, y={Y}) PUT /PHOTO_ID/tags/USER_ID FB r(‘is-tagged-in’, {USER_ID}, Photo) GET /USER_ID/photos FB r(‘is-tagged-in’, {USER_ID}, Video) GET /USER_ID/videos FB created c(‘created’, {USER_ID}, {PLACE_OBJECT}) POST /venues/add FS POST /geo/place TW r(‘created’, User, {COLLECTION_ID}) GET /lists/LIST_ID FS c(‘created’, {USER_ID}, {COLLECTION_OBJECT}) POST /lists/add FS POST /USER_ID/albums FB u(‘created’, {USER_ID}, {COLLECTION_ID}, Collection.name={NAME}, ...) POST /lists/LIST_ID/update FS r(‘created’, {USER_ID}, GET /USER_ID/albums FB 87 OpenMe relationship Usage API Method OSN Collection, Collection.type=Photo) c(‘created’, {USER_ID}, {EVENT_OBJECT}) POST /USER_ID/events FB u(‘created’, {USER_ID}, {EVENT_OBJECT}) POST /EVENT_ID FB d(‘created’, {USER_ID}, {EVENT_ID}) DELETE /EVENT_ID FB added-to r(‘added-to’, User, Collection, Object.id={PLACE_ID}) GET /venues/VENUE_ID/listed FS r(‘added-to, User, Collection, Object.id={POST_ID}) GET /tips/TIP_ID/listed FS c(‘added-to’, {USER_ID}, {COLLECTION_ID}, Object.id={PLACE_ID | POST_ID}) POST /lists/LIST_ID/additem FS d(‘added-to’, {USER_ID}, {COLLECTION_ID}, Object.id={PLACE_ID | POST_ID}) POST /lists/LIST_ID/deleteitem FS u(‘added-to’, {USER_ID}, {COLLECTION_ID}, Object.id={PLACE_ID | POST_ID}, beforeId={BEFORE_ID}, afterId={AFTER_ID}) POST /lists/LIST_ID/moveitem FS r(‘added-to’, User, {GROUP_ID}, Object.type=Document) GET /GROUP_ID/docs FB r(‘added-to’, {USER_ID}, FAVOURITES}, Object.type=Post) GET /favorites TW c(‘added-to’, {USER_ID}, FAVOURITES, Object.id={POST_ID}) POST /favorites/create/:id TW d(‘added-to’, {USER_ID}, FAVOURITES, Object.id={POST_ID}) POST /favorites/destroy/:id TW sent-message- r(‘sent-message-to’, User, {USER_ID}) GET /direct_messages TW 88 OpenMe relationship Usage API Method OSN to r(‘sent-message-to’, User, {USER_ID}, isRead=false) GET /USER_ID/updates FB r(‘sent-message-to’, {USER_ID}, User) GET /direct_messages/sent TW GET /USER_ID/outbox FB d(‘sent-message-to’, User, {USER_ID}, Message.id={MESSAGE_ID}) POST /direct_messages/destroy/:i d TW c(‘sent-message-to’, {USER_ID}, {USER_ID}, Message.text={TEXT}) POST /direct_messages/new TW r(‘sent-message-to’, User, User, Message.id={MESSAGE_ID}) GET /direct_messages/show/:id TW GET /MESSAGE_ID FB B.3 OSN Table 30.  OSN specific functionality that OpenMe OSN abstractions relationships can abstract. OpenMe relationship Usage API Method OSN has r(‘has’, OSN, User, User.id={USER_ID}) GET /users/USER_ID FS GET /users/show TW GET /USER_ID FB r(‘has’, OSN, User, User.name={USER_NAME}, User.email={USER_EMAIL}, ...) GET or POST /users/search FS GET /users/search TW u(‘has’, OSN, {USER_ID}, User.photo=byte[], ...) POST /users/self/update FS POST /account/update_profile TW r(‘has’, OSN, {PLACE_ID}) GET /venues/VENUE_ID FS GET /geo/id/:place_id TW r(‘has’, OSN, PlaceCategories) GET /venues/categories FS r(‘has’, OSN, Place, Place.name={PLACE_NAME}, ...) GET /venues/search FS GET /geo/search TW 89 OpenMe relationship Usage API Method OSN r(‘has’, OSN, Event, Event.placeId={PLACE_ID}) GET /venues/VENUE_ID/events FS u(‘has, OSN, {PLACE_ID}, Place.name={PLACE_NAME}, ...) POST /venues/VENUE_ID/edit FS POST /venues/VENUE_ID/proposeedi t FS r(‘has’, OSN, {EVENT_ID}) GET /events/EVENT_ID FS GET /EVENT_ID FB r(‘has’, OSN, EventCategories) GET /events/categories FS r(‘has’, OSN, Post, Post.text={TEXT}, ...) GET /search TW r(‘has’, OSN, {GROUP_ID}) GET /GROUP_ID FB B.4 Location Table 31.  OSN specific functionality that OpenMe location relationships can abstract. OpenMe relationship Usage API Method OSN is-located-at r(‘is-located-at’, User, {PLACE_ID}) GET /venues/VENUE_ID/herenow FS c(‘is-located-at’, {USER_ID}, {PLACE_ID}) POST /checkins/add FS POST /USER_ID/checkins FB was-located- at r(‘was-located-at’, {USER_ID}, Place) GET /users/USER_ID/checkins FS GET /USER_ID/checkins FB r(‘was-located-at’, {USER_ID}, Place, Location.id={LOC_ID}) GET /checkins/CHECKIN_ID FS r(‘was-located-at’, {USER_ID}, Place, Location.date=RECENT) GET /checkins/recent FS is-near r(‘is-near’, ‘{USER_ID}’, Place) GET /venues/explore FS r(‘is-near’, ‘{USER_ID}’, Place, Place.name={PLACE_NAME}, ...) GET /venues/suggestcompletion FS 90 B.5 Desires and Deeds Table 32.  OSN specific functionality that OpenMe desires and deeds relationships can abstract. OpenMe relationship Usage API Method OSN wants-to-be- mutual-with r(‘wants-to-be-mutual- with’, {USER_ID}, User) GET /users/requests FS GET /friendships/outgoing TW r(‘wants-to-be-mutual- with’, User, {USER_ID}) GET /friendships/incoming TW GET /USER_ID/friendrequests FB wants-to-complete c(‘wants-to-complete’, {USER_ID}, {POST_ID}) POST /tips/TIP_ID/marktodo FS d(‘wants-to-complete’, {USER_ID}, {POST_ID}) POST /tips/TIP_ID/unmark FS wants-to-visit r(‘wants-to-visit’, {USER_ID}, {PLACE_ID}) POST /venues/VENUE_ID/marktodo FS has-completed r(‘has-completed, User, {POST_ID}) GET /tips/TIP_ID/done FS c(‘has-completed, {USER_ID}, {POST_ID}) POST /tips/TIP_ID/markdone FS wants-to-attend r(‘wants-to-attend’, User, {EVENT_ID}) GET /EVENT_ID/attending FB r(‘wants-to-attend’, User, {EVENT_ID}, maybe=true) GET /EVENT_ID/maybe FB r(‘!wants-to-attend’, User, {EVENT_ID}) GET /EVENT_ID/declined FB r(‘wants-to-attend’, {USER_ID}, Event) GET /USER_ID/events FB c(‘wants-to-attend’, {USER_ID}, {EVENT_ID}) POST /EVENT_ID/attending FB c(‘wants-to-attend’, {USER_ID}, {EVENT_ID}, maybe=true) POST /EVENT_ID/maybe FB c(‘!wants-to-attend’, {USER_ID}, {EVENT_ID}) POST /EVENT_ID/declined FB 91 B.6 Unsupported OSN Functionality Table 33.  OSN specific functionality that is not supported in this iteration of OpenMe. Unsupported OSN Endpoint OSN Reason GET /venues/VENUE_ID/menu FS not a relationship, more of an object property, but we do not have a Menu object GET /venues/VENUE_ID/similar FS no relationship to support this GET /lists/LIST_ID/suggestphoto FS no relationship to support this GET /lists/LIST_ID/suggesttip FS no relationship to support this GET /lists/LIST_ID/suggestvenues FS no relationship to support this GET /venues/trending FS no relationship to support this GET /specials/SPECIAL_ID FS no relationship to support this GET /specials/add FS no relationship to support this GET /specials/list FS no relationship to support this GET /specials/search FS no relationship to support this GET /specials/configuration FS no relationship to support this GET /specials/retire FS no relationship to support this GET /statuses/oembed TW does not need to be abstracted, OpenMe could provide a service that is similar to this for embedding posts outside of OSNs in arbitrary places, but we currently do not GET /friendships/lookup TW this is a “what is the relationship” kind of query, which is not supported in OpenMe GET /users/suggestions TW no relationship to support this GET /users/suggestions/:slug TW no relationship to support this GET /users/suggestions/:slug/members.format TW no relationship to support this POST /lists/create TW we do not represent user lists as an object but rather as relationships with labels, so we cannot have an empty “knows” relationship label 92 Unsupported OSN Endpoint OSN Reason GET /saved_searches TW no relationship to support this GET /saved_searches/show/:id TW no relationship to support this POST /saved_searches/create TW no relationship to support this POST /saved_searches/destroy/:id TW no relationship to support this GET /trends/:woeid TW no relationship to support this GET /trends/available TW no relationship to support this GET /trends/daily TW no relationship to support this GET /trends/weekly TW no relationship to support this GET /geo/reverse_geocode TW this is a service, it does not have anything to do with creating connections between objects, but we currently have no such service GET /geo/similar_places TW no relationship to support this GET /EVENT_ID/noreply FB no relationship to support this GET /PROFILE_ID/activities FB no Activity object to support this GET /PROFILE_ID/books FB no Book object to support this GET /PROFILE_ID/interests FB no Interest object to support this GET /PROFILE_ID/movies FB no Movie object to support this GET /PROFILE_ID/music FB no Music object to support this GET /PROFILE_ID/mutualfriends FB no relationship to support this GET /PROFILE_ID/television FB no Television object to support this GET /PROFILE_ID/pokes FB no relationship to support this 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.24.1-0072662/manifest

Comment

Related Items