Download
advanced development on the open source vivo project n.
Skip this Video
Loading SlideShow in 5 Seconds..
Advanced Development on the Open Source VIVO Project PowerPoint Presentation
Download Presentation
Advanced Development on the Open Source VIVO Project

Advanced Development on the Open Source VIVO Project

142 Views Download Presentation
Download Presentation

Advanced Development on the Open Source VIVO Project

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Advanced Development on the Open Source VIVO Project 2011 VIVO Conference

  2. Welcome

  3. Goals of the intro workshop • Connect you to the VIVO Application by building and deploying from the VIVO repositories • Connect you to the VIVO Architecture by modifying VIVO • Connect you to the VIVO community

  4. Topic in the intro workshop • Deploying VIVO • Application overview • Modifying VIVO • Theme’s • Custom listviews • Developer tools • Linked open data • The VIVO community

  5. Goals of this Workshop • An In-depth understanding of VIVO’s architecture • Open discussion of your plans for VIVO • Hands on Experience with VIVO Developers

  6. Schedule • Part 1 • Introduction • Overview • Application (Code) • Ontology (Data) • BREAK: 15 min • Part 2 • Advanced VIVO Concepts • Rich Export • Freemarker • Test Driven Development using the VIVO Security Model • BREAK: 15 min • Part 3 • Roundtable and Breakout Session (your projects) • Committing Changes to VIVO • Closing Discussion

  7. Overview of Application Architecture and Review of Application Flow

  8. Application flow overview System startup Servlet context Context listeners Solr indexer policies Freemarker configuration file system Configuration properties HTTP Request Controllers Freemarker Templates Servlet filters HTTP Response models data filters DAOs Application bean Request Session Editing session status User Account

  9. Application architecture

  10. VIVO Ontology & extending it

  11. Role of the ontology in VIVO • Provides the core data model for the application • maximize display; minimize entry • capture semantics of data: semantic search, analysis • sharing data on the national network • Configures application display and editing behavior • But ontology doesn’t have familiar notion of constraints • Currently the VIVO application interprets some OWL axioms as if they were constraints • Moving towards more separation

  12. Ontology as data model • Make data independent of the application • Combine data with other semantic web applications • You will likely need to align ontologies and/or map data • Leverage substantial body of existing ontology work to extend the application • Open source code • Jena, other triple stores, reasoners, Drupal

  13. OWL Basics • Classes • the kinds of things you want to talk about • Represent a collection of individuals, aka instances, aka members • Properties • what you want to say about those things • represent relationships between things • object properties: relate individuals to other individuals • datatype properties: relate individuals to literals (e.g. string, number) • annotation properties: relate anything to anything and have no semantics

  14. Demonstration

  15. Guidelines for ontology development

  16. VIVO ontology context nodes • Represent N-ary relationships and temporal modeling • Examples: • Position, Role • time bounds, and other qualifying information • Authorship • to represent author order

  17. VIVO ontology

  18. Vitro annotations can be changed • Ontology editing forms have annotations that can be changed that adjust the following: • Display • Level • Ranking • Sorting • Label (name) • Class and property groups

  19. Editing a class

  20. Editing an object property

  21. Editing a datatype property

  22. VIVO Core • VIVO core needs to be shared to support inference on shared data and search • What not to change • Class and property URIs and relationships in the hierarchy • Restrictions • Domain and Range axioms • Datatype property range datatypes

  23. Guidelines for extending the ontology • Look for examples from existing ontologies • re-use classes and properties where possible • Model only the necessary level of detail • understand what data you will get • extend when there is a clear use case • Class vs. property • sub grant

  24. Demonstration • Navigating the class and property hierarchy • Adding a class • classgroup • Adding a property • controlling display • property group • display order • domain • Creating a menu page

  25. Ontology files in the repository

  26. Break 1 15 min break We will start again at X:XX AM

  27. Rich Export Supplemental Linked Open Data

  28. What is rich export? • Easily retrieve RDF that includes more extensive information about a person • data model dependent • Developed in support of Digital Vita mini-grant • other use cases also • CALS Impact Site data -- projects and associated information such as participants and related geographic areas

  29. Design features • Build upon the linked open data support • Parameter on standard LOD request: • include=<directory name> • All files in named directory and its subdirectories • special keyword “all” • Transparency • SPARQL construct queries generate content returned • Can be modified without recompile • or restarting the system

  30. Implementation details • Extends code for linked open data support • SPARQL constructs written to build upon extended linked open data • Next steps: performance

  31. Runtime flow HTTP Request target uri target uri Source model ExtendedLinkedDataUtils edu.cornell.mannlib.vitro.webapp.utils.jena Individual Controller send info for display Freemarker template (and more…)

  32. Demonstration • Extend rich-export to include a person’s clinical activities

  33. Model-View-Controller Architecture and FreeMarker

  34. MVC with controllers and JSPs Controller Browser HTTP request View (JSPs) HTTP response Data store Model

  35. Advantages of MVC • The data assembled by the controllers can be presented by different views • A site can be reskinned without touching the application logic • Application logic can be modified without affecting the presentation • UI and application teams can work with maximum independence • Not completely separate, since views and controllers are closely connected

  36. The problem with JSPs • Allow mixing of application logic with presentation logic • Java code embedded in JSP files • The line between controllers and views can get blurred… • Markup and presentation logic embedded in Java classes (servlets, custom JSP tags)

  37. Other limitations of JSPs • Controller relinquishes control of the request and response when it forwards to the JSP • Tag-based syntax is overly verbose • Multiple syntaxes, each with different variable access • Java code in JSPs is not precompiled

  38. What is FreeMarker? • An all-purpose Java template engine for generating text output based on templates • Not specifically designed to generate web pages, so text generation is independent of the servlet application architecture

  39. MVC with FreeMarker Controller Browser HTTP request HTTP response View (FreeMarker templates) Model Data store

  40. MVC with controllers and JSPs Controller Browser HTTP request View (JSPs) HTTP response Data store Model

  41. FreeMarker features • Separation of application and presentation logic is enforced through: • Syntactic limitations of the template language • Exposure settings on the template data • Only FTL is allowed in templates • No Java code • Template language • Clean, simple, and consistent • Just powerful enough • Loops, conditionals, local variables, macros, object property access, convenient built-in functions

  42. FreeMarker features • String capture • Controller can use the engine to generate a string without relinquishing control of the request • Flexible and powerful API • Thorough documentation • API documentation • Template developer documentation • Active user mailing list

  43. FreeMarker Basics Templates and Data Models

  44. Templates and data models Map<String, Object> data = new HashMap<String, Object>(); data.put(“name”, “John”); Free- Marker <p> Hello, John. </p> <p> Hello, ${name}. </p>

  45. Use the string • Send to the browser PrintWriter out = response.getWriter(); out.print(sw); • Use as the body of an email message MimeMessage msg = new MimeMessage(session); msg.setContent(sw.toString(), “text/html”); Transport.send(msg); • Add to the data model of another template map.put(“pageBody”, sw); • Write to a file on the server • Send a response to an Ajax request

  46. The VIVO Implementation of FreeMarker

  47. Two ways to use FreeMarker in VIVO • Generate an entire page in FreeMarker • This is the direction the application is moving in; transition is still incomplete • Generate a string for use outside a FreeMarker page • In the transition from JSPs, generate page headers, footers, menus, etc. using the same FreeMarker templates used in generating whole pages • Email messages • Ajax responses

  48. Anatomy of a VIVO FreeMarker controller FreemarkerHttpServlet doGet(): Calls processRequest() Generates body text using values from processRequest() Puts body text into the page data model Adds page-level values to page data model Generates the page string Sends the page to the browser MyController extends FreemarkerHttpServlet @Override processRequest(): Specifies body template name and body data model

  49. Sample Freemarker controller public class AboutController extends FreemarkerHttpServlet { private static final String TEMPLATE_DEFAULT = "about.ftl"; @Override protected ResponseValues processRequest(VitroRequest vreq) { ApplicationBean application = vreq.getAppBean(); Map<String, Object> body = new HashMap<String, Object>(); body.put("aboutText", application.getAboutText()); body.put("acknowledgeText", application.getAcknowledgeText()); return new TemplateResponseValues(TEMPLATE_DEFAULT, body); } @Override protected String getTitle(String siteName, VitroRequest vreq) { return "About " + siteName; } }

  50. Giving the controller more control • processRequest() can return a different type of object to trigger a forward, redirect, or error • Override FreemarkerHttpServlet.doGet() • Use methods defined in FreemarkerHttpServlet as needed to generate a page