2009 ctsa profiles opensocial poster

1
Building a Framework for Distributed Innovation in Research Networking with the OpenSocial Standard Eric Meeks, Jeff Wang, Maninder Kahlon Clinical and Translational Science Institute, University of California, San Francisco (UCSF) The proliferation of social networking sites such as LinkedIn, MySpace, and Facebook has changed the way we use the internet as a tool for communication and discovery. With their increasing adoption users have found new and creative ways to harness these networking sites for extended functionality and this has led to the phenomena of social networking applications. Networking sites are now more than just applications, they are platforms. A multitude of “gadgets” have been developed for running on these platforms. OpenSocial is an industry backed movement to define a single application programming interface (API) for web based social networking applications. With OpenSocial, a widget written for one networking site (an OpenSocial container) will run on a different networking site (LinkedIn) with little or no alteration. The Harvard Catalyst-developed Profiles application allows us to take the advances in communication and discovery that are core to social networking sites and begin to utilize them to improve the research collaboration processes. UCSF is now extending Profiles to become an OpenSocial container. Introduction Methods Specific Aims Make Profiles an OpenSocial container by implementing the OpenSocial API as defined at http://www.opensocial.org/specs. Expand the functionality of Profiles by developing, porting, and/or finding widgets that interact with Profiles via the OpenSocial API. Port existing OS applications to Profiles to pirate functionality. Expand functionality in Profiles without altering the source code. OpenSocial Gadgets Gadgets are dynamic web applications that run on the “canvas” of an OpenSocial container. Gadgets are defined in XML and a simple gadget can be just a single XML file containing HTML and JavaScript. A gadget can make API calls into the container to access data such as “who’s page am I looking at” and “who is in their immediate network”. Advanced gadgets can have a server side component. While this is more complex, it allows for virtually limitless functionality. The server side component can live anywhere on the internet. Communication between the gadget and the server is brokered by the container, which can layer in security and the caching of static content. Reference UCSF Profiles with OpenSocial Link Navigation Gadget (Similar People) Navigation Gadget (Co-Authors) Results Results (continued) Acknowledgments This project was supported by NIH/NCRR UCSF-CTSI Grant Number UL1 RR024131. Its contents are solely the responsibility of the authors and do not necessarily represent the official views of the NIH. We would like to thank Griffin Weber, Ken Huling, Paul Gomez and Harvard, the creators of the Profiles application. We would also like to thank the communities supporting the following web sites: http://www.opensocial.org/ http://code.google.com/apis/opensocial/ http://incubator.apache.org/shindig/ Conclusion The current primary benefit of OpenSocial for Profiles is in making Profiles a platform for gadgets. Expanding functionality with gadgets has the following advantages: o Gadgets are pluggable and external to Profiles. Developing gadgets allows us to extend Profiles without having to edit the Profiles source code. This is much more scalable and less risk prone than editing the Profiles source, especially when Profiles becomes installed at many institutions. o Gadgets are easy to build. The minimal technical skill set for simple gadgets is JavaScript and HTML. Complex gadgets with server side components can be developed in any server side language (.NET, Java, Python, PHP, Ruby, etc.) o Gadgets are efficient. Much of the base cost of building web enabled functionality is handled by the underlying OpenSocial container. Porting existing gadgets into Profiles is not seamless, but is helpful as a starting point for extended functionality. Using OpenSocial as a way to benefit from existing gadgets will be increasingly beneficial, but currently does not offer much return value. We have been successful in demonstrating “proof of concept” gadgets with the proposed architecture. Porting existing gadgets into Profiles is not seamless. The interesting gadgets currently depend on data and API calls that are beyond the current scope of the OpenSocial API, and are thus proprietary and not easily ported. A reference implementation of an OpenSocial container is being maintained by Apache at http://incubator.apache.org/shindig/ Alter Shindig to work with the Profiles data model. The current implementation uses the Profiles web services API for all communication between Profiles and Shindig. Future implementations will require a direct DB link from the altered version of Shindig into the Profiles database for deeper integration. Create a “proof of concept” by extending Profiles functionality via an OpenSocial gadget. Methods (continued) Server Architecture Windows Server SQL Server Profiles Web (IIS) Windows or Linux Server Java DB Gadget Data Storage Altered Shindig (Tomcat) Profiles Web Services (IIS) Internet

Upload: ericmeeks

Post on 21-Jan-2015

204 views

Category:

Health & Medicine


0 download

DESCRIPTION

 

TRANSCRIPT

Page 1: 2009 CTSA Profiles OpenSocial Poster

Building a Framework for Distributed Innovation in Research Networking

with the OpenSocial Standard

Eric Meeks, Jeff Wang, Maninder Kahlon

Clinical and Translational Science Institute, University of California, San Francisco (UCSF)

• The proliferation of social networking sites such as LinkedIn,

MySpace, and Facebook has changed the way we use the internet

as a tool for communication and discovery. With their increasing

adoption users have found new and creative ways to harness these

networking sites for extended functionality and this has led to the

phenomena of social networking applications.

• Networking sites are now more than just applications, they are

platforms. A multitude of “gadgets” have been developed for running

on these platforms.

• OpenSocial is an industry backed movement to define a single

application programming interface (API) for web based social

networking applications. With OpenSocial, a widget written for one

networking site (an OpenSocial container) will run on a different

networking site (LinkedIn) with little or no alteration.

• The Harvard Catalyst-developed Profiles application allows us to take

the advances in communication and discovery that are core to social

networking sites and begin to utilize them to improve the research

collaboration processes. UCSF is now extending Profiles to become

an OpenSocial container.

Introduction

Methods

Specific Aims

• Make Profiles an OpenSocial container by implementing the

OpenSocial API as defined at http://www.opensocial.org/specs.

• Expand the functionality of Profiles by developing, porting, and/or

finding widgets that interact with Profiles via the OpenSocial API.

• Port existing OS applications to Profiles to pirate functionality.

• Expand functionality in Profiles without altering the source code.

OpenSocial Gadgets

• Gadgets are dynamic web applications that run on the “canvas” of an

OpenSocial container.

• Gadgets are defined in XML and a simple gadget can be just a single

XML file containing HTML and JavaScript. A gadget can make API

calls into the container to access data such as “who’s page am I

looking at” and “who is in their immediate network”.

• Advanced gadgets can have a server side component. While this is

more complex, it allows for virtually limitless functionality. The server

side component can live anywhere on the internet. Communication

between the gadget and the server is brokered by the container,

which can layer in security and the caching of static content.

Reference

UCSF Profiles with OpenSocial Link

Navigation Gadget (Similar People)

Navigation Gadget (Co-Authors)

Results Results (continued)

Acknowledgments

This project was supported by NIH/NCRR UCSF-CTSI Grant Number

UL1 RR024131. Its contents are solely the responsibility of the authors

and do not necessarily represent the official views of the NIH.

We would like to thank Griffin Weber, Ken Huling, Paul Gomez and

Harvard, the creators of the Profiles application.

We would also like to thank the communities supporting the following

web sites:

http://www.opensocial.org/

http://code.google.com/apis/opensocial/

http://incubator.apache.org/shindig/

Conclusion

• The current primary benefit of OpenSocial for Profiles is in making

Profiles a platform for gadgets. Expanding functionality with gadgets

has the following advantages:

o Gadgets are pluggable and external to Profiles. Developing

gadgets allows us to extend Profiles without having to edit the

Profiles source code. This is much more scalable and less risk

prone than editing the Profiles source, especially when Profiles

becomes installed at many institutions.

o Gadgets are easy to build. The minimal technical skill set for

simple gadgets is JavaScript and HTML. Complex gadgets with

server side components can be developed in any server side

language (.NET, Java, Python, PHP, Ruby, etc.)

o Gadgets are efficient. Much of the base cost of building web

enabled functionality is handled by the underlying OpenSocial

container.

• Porting existing gadgets into Profiles is not seamless, but is helpful

as a starting point for extended functionality. Using OpenSocial as a

way to benefit from existing gadgets will be increasingly beneficial,

but currently does not offer much return value.

• We have been successful in demonstrating “proof of concept”

gadgets with the proposed architecture.

• Porting existing gadgets into Profiles is not seamless. The interesting

gadgets currently depend on data and API calls that are beyond the

current scope of the OpenSocial API, and are thus proprietary and

not easily ported.

• A reference implementation of an OpenSocial container is being

maintained by Apache at http://incubator.apache.org/shindig/

• Alter Shindig to work with the Profiles data model. The current

implementation uses the Profiles web services API for all

communication between Profiles and Shindig.

• Future implementations will require a direct DB link from the altered

version of Shindig into the Profiles database for deeper integration.

• Create a “proof of concept” by extending Profiles functionality via an

OpenSocial gadget.

Methods (continued)

Server Architecture

Windows Server

SQL Server

Profiles Web

(IIS)

Windows or

Linux Server

Java DB

Gadget Data

Storage

Altered

Shindig

(Tomcat)

Profiles

Web Services

(IIS)

Internet