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

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 Center
Introduction Methods Results Example Data
Research 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 Weber
widespread 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 OpenSocial
becoming 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 OpenSocial
tools, 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 FOAF
expression. 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 tool
serialization 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 interoperability
groups 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, which
Network, 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 the
UCSF 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 into
building 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, provided
Profiles 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 Networking
Problem 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 reused
RDF 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 page
for application support such as user interface, deployment model, owner to automatically query the DIRECT network to find similar
security/authentication and data model. researchers across multiple institutions. DIRECT Match has been SIMILE
successfully tested with RDF content from both Profiles and VIVO. Babel
The data model within OpenSocial, particularly those parts centered
around people and connections, are not well matched for the
biomedical research domain. The default fields that describe a person
and connections reflect the consumer and business oriented market OpenSocial with RDF/XML JSON for Griffin Weber
where OpenSocial originated, and do not align with the academic
definition of a researcher. A standard OpenSocial person has methods
for friends and movies but not for co-authors or publications.
OpenSocial allows for custom extensions of the data model. But Browser
customizations break interoperability. At UCSF we could manually OR*
extend OpenSocial to reflect the fields and connections that define our
researchers but the larger goal is to gain adoption within the research
networking community so that applications built to extend our platform
HTML Content
can easily be shared amongst other institutions. With RDF and the
RDF/XML
existing support for standard ontologies such as VIVO and FOAF we
can achieve this larger goal.
Approach
Domain Object Request
OpenSocial applications use JavaScript and JSON to execute within
the browser. The domain objects in OpenSocial (ex. people, movies, Babel
Next Steps
friends in the consumer oriented world or researcher, publications, co-
JSON Domain Data
authors in the bioinformatics world) need to be expressed as JSON to Release Profiles-based integration to open source community. This is
be available to OpenSocial applications. currently targeted for the 1.2 release of Profiles.
Acknowledgments
The JSON encoding typically happens through a custom development Gadget Content Use the OpenSocial Security Token to create data access mechanisms
Gadget
effort (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 Number
institutions 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 not
another 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 convenience
With 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 other
technologies 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 child
used 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.