Advanced Development on the Open Source VIVO Project

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