Extending OpenSocial with RDF to Benefit Research Networking Tools                                                        ...
Upcoming SlideShare
Loading in …5

VIVO 2011 OpenSocial and RDF Poster


Published on

Presentation on combining OpenSocial with RDF to allow for better domain data access

Published in: Technology, Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

VIVO 2011 OpenSocial and RDF Poster

  1. 1. Extending OpenSocial with RDF to Benefit Research Networking Tools Eric Meeks (UCSF), Leslie Yuan (UCSF), Griffin Weber (Harvard), Maninder Kahlon (UCSF) Clinical and Translational Science Institute, University of California, San Francisco Harvard Catalyst, The Harvard Clinical and Translational Science CenterIntroduction Methods Results Example DataResearch Networking Tools such as VIVO and Profiles have found UCSF extended Profiles to become an OpenSocial container by OpenSocial applications can now be developed for specific domain RDF/XML for Griffin Weberwidespread adoption in the biomedical research community. RDF is integrating Profiles with Shindig, a product maintained by the Apache needs without overtaxing interoperability. For example, an OpenSocialbecoming a primary means for exposing the data contained within these Software Foundation. Shindig is an open source Java product that is the application built for the VIVO ontology will work within any OpenSocialtools, and the VIVO ontology has become the standard vocabulary for reference standard for the OpenSocial API, and is the most commonly Research Networking Tool that produces VIVO RDF. Moreover, a FOAFexpression. Both VIVO and Profiles export data through the RDF/XML used code base for making a web site OpenSocial compliant. based OpenSocial application would also work with a VIVO based toolserialization format. because the VIVO ontology is an extension of FOAF. Essentially, this The Babel application from the SIMILE Project (Simple Interoperability RDF approach allows OpenSocial to become domain model agnostic.OpenSocial is a standard API for running embedded applications of Metadata and Information in unLike Environments) at MIT proved(gadgets) within a containing web site. OpenSocial is supported by successful in being able to convert RDF/XML from both Profiles and Consistent domain model resolution is still required for interoperabilitygroups within industry and research such as Google, LinkedIn, Nature VIVO into usable JSON. Babel is open source and like Shindig, but this problem will instead be solved by the use of ontologies, whichNetwork, and Elsevier SciVerse. developed in Java. offer a more sophisticated answer than the “one size plus extensions fits all” approach currently found within OpenSocial. From theUCSF Profiles supports the OpenSocial standard and UCSF has been UCSF integrated Babel into Shindig and created an OpenSocial feature OpenSocial perspective this approach should allow easier adoption intobuilding a shareable library of OpenSocial applications to extend extension to automatically create People JSON objects that are sourced vertical markets such as academia, research, or enterprise, providedProfiles functionality. by RDF. Our OpenSocial People objects now have attributes such as that the vertical market is willing to adopt RDF. authorInAuthorship and hasResearchArea that are meaningful to our domain. In OpenSocial, our People now look like researchers! The implementation effort for other RDF based Research NetworkingProblem Tools (such as VIVO) to become OpenSocial compliant is now reduced A demonstration gadget called DIRECT Match was built as a proof of because the code for converting domain objects to JSON can be reusedRDF is a data oriented standard whereas OpenSocial is an application concept. DIRECT Match uses the VIVO ontology defined among any Research Networking Tool that produces RDF/XML.standard. By necessity OpenSocial contains and references standards hasResearchArea and freetextKeyword attributes of the home pagefor application support such as user interface, deployment model, owner to automatically query the DIRECT network to find similarsecurity/authentication and data model. researchers across multiple institutions. DIRECT Match has been SIMILE successfully tested with RDF content from both Profiles and VIVO. BabelThe data model within OpenSocial, particularly those parts centeredaround people and connections, are not well matched for thebiomedical research domain. The default fields that describe a personand connections reflect the consumer and business oriented market OpenSocial with RDF/XML JSON for Griffin Weberwhere OpenSocial originated, and do not align with the academicdefinition of a researcher. A standard OpenSocial person has methodsfor friends and movies but not for co-authors or publications.OpenSocial allows for custom extensions of the data model. But Browsercustomizations break interoperability. At UCSF we could manually OR*extend OpenSocial to reflect the fields and connections that define ourresearchers but the larger goal is to gain adoption within the researchnetworking community so that applications built to extend our platform HTML Contentcan easily be shared amongst other institutions. With RDF and the RDF/XMLexisting support for standard ontologies such as VIVO and FOAF wecan achieve this larger goal.Approach Domain Object RequestOpenSocial applications use JavaScript and JSON to execute withinthe browser. The domain objects in OpenSocial (ex. people, movies, Babel Next Stepsfriends in the consumer oriented world or researcher, publications, co- JSON Domain Dataauthors in the bioinformatics world) need to be expressed as JSON to Release Profiles-based integration to open source community. This isbe available to OpenSocial applications. currently targeted for the 1.2 release of Profiles. AcknowledgmentsThe JSON encoding typically happens through a custom development Gadget Content Use the OpenSocial Security Token to create data access mechanisms Gadgeteffort (extending Apache Shindig) specific to the implementing Specs for control of who can see what data. This would allow sensitive data to This project was supported by NIH/NCRR UCSF-CTSI Grant Numberinstitutions technical infrastructure. One institution might store domain be safely folded into Linked Open Data for OpenSocial applications. UL1 RR024131 and Harvard Catalyst Grant Number 1 UL1 RR025758-data in an Oracle database with a particular set of tables and columns, 01. Its contents are solely the responsibility of the authors and do notanother institution might use SQL Server, etc. Babel is ontology agnostic. Determine need for ontology specific necessarily represent the official views of the NIH. Gadget Hosting Servers OpenSocial features, such as VIVO-ontology oriented convenienceWith RDF, a reusable coding effort is possible by using existing functions to easily access co-authors, publications and more. We would like to thank MIT Libraries and MIT CSAIL as well as all othertechnologies such as SIMILE Babel from MIT to convert the RDF/XML http://anywhere/gadget.xml contributors to the SIMILE Project.expression of the domain data to JSON in a form that can be readily Assess need for an “eager fetching” strategy to convert referenced childused by OpenSocial applications. * Successfully tested with VIVO (ask for demo!) but not yet implemented. RDF/XML data to JSON and implement if necessary. We would also like to thank Andy Smith and the OpenSocial foundation.