Skip to end of metadata
Go to start of metadata

RS3.1 draft by Jana

Components overview

The ResearchSpace architecture consists of four major components:

  • OWLIM
    This is the RDF repository. It stores RDF schema and RDF data. We use CIDOC-CRM data model with a few extensions. Data can be accessed via SPARQL. OWLIM provides its functionality through several standard APIs and the recommended API is Sesame OpenRDF.
    Responsibilities of OWLIM in the ResearchSpace project:
    • Stores RDF data and RDF schema. Allows for insert, update and retrieve operations
    • Provides all search functionality for ResearchSpace - including full text search, structured search etc. It is to be noted here that we won't rely on DMS to provide full-text search. The rationale behind this is to avoid federated search - when searching in both documents and RDF data. Thus we will need to send to OWLIM all searchable data that has originated/been updated in DMS. For details - see interface descriptions. TODO
  • DMS
    We have based this component on Nuxeo DM. Its main responsibilities are:
    • Handle and implement most of the GUI requirements - navigation, themes etc. Some of the GUI would be used as-is - this mostly refers to document management (view, upload, print, publish etc.) and access control (workspaces, roles, login etc.).
      We may need to modify some built-in GUI - this, for example, includes search criteria forms and search results forms and the forum/blog pages.
      Additionally, we will add some brand-new GUI - custom view/edit forms for Museum Objects, image zoom and annotation tool, ResearchSpace toolbar and others.
    • Provide out-of-the-box functionality
    • Provide extension platform for new functionality due to its plugin-based OSGi architecture and flexible extension points mechanisms.
    • Provide out-of-the-box support for a number of open standards - like CMIS
    • Manage access control and enforce it on OWLIM data
  • Browser
    The ResearchSpace application has Web GUI. This is not something unusual but we are considering the browser as a separate component as we plan to use JavaScript/HTML/CSS heavily to achieve some of the core application's functionality.
    We plan to use third-party libraries and components and implement our own as well.
    After researching the available options, we consider the following to be very strong candidates to match our needs:
    • Simile Exhibit: We will use it to show lists of objects in an elaborate manner. It supports pagination, facet view, various layout styles and timeline view. It works entirely in the browser using data arrays of maximum 1000 items. Data is in JSON format
    • RForms (ex-Shame) project: This is a JavaScript library based on dojo. It provides a rendering engine for view/edit forms that are based on rdf data and layout templates. Both data and templates are JSON. RForms allow for both RDF data visualization and editing. We would need to extend RForms in order to implement the planned look-and-feel.
      Basically, we will have one large view template for showing all data for a Museum Object and we will have smaller edit templates for each editable node.
    • Aloha WYSIWYG editor: Aloha has great UI based on HTML5. In addition to its obvious usage as a format toolbar, it can be extended to implement the ResearchSpace toolbar holding a number of handy actions that correspond to the current application context.
    • IIP Image JavaScript client (IIPMooViewer): IIP Image is a client-server application for deep zoom. The server supports several communication protocols. There are number of clients that can work with the IIP Image server - both free and commercial. IIPMooViewer 2.0 beta supports region annotations. It is HTML5/JavaScript based. It also supports image overlay.
  • IIP Image Server
    After evaluating several possible solutions, we have decided to use IIP Image Server to store and server multiresolution images and tiles.

Interfaces

  • DMS - OWLIM
    • Entity API layer
      Entity API will be used by DMS modules for simplified access to OWLIM functionality. Some tasks it is going to handle:
  1. Hide communication complexity - like whether OWLIM is accessed locally or remotely, what API is used to access it etc.
  2. Retrieve full representation for a given resource as needed by the GUI layer
  3. Provide Search API
  4. Provide interface for data modification
    • Index and Search
      All the search functionality will be implemented in OWLIM. Specifically, for full-text search we need to handle all text modification events and to update relevant RDF data.
      Every time a document is updated, created or deleted, we need to update triples in OWLIM and trigger reindexing.
    • Workspaces, Named Graphs and access control
      Every project in ResearchSpace has its own workspace in DMS. Each workspace has assigned users in different roles. Documents in an workspace are visible only to users that have the appropriate access rights.
      For each project in OWLIM we have a separate named graph. This graph holds only statements that are produced or valid for the specific project. These statements are not visible to other projects - until they get published.
      Thus, a workspace in DMS corresponds to a named graph in OWLIM and both relate to a research project, its members and findings.
      Access control is a responsibility of the DMS:
  5. When creating a new project workspace, a new named graph is created in OWLIM and all the initial project documents are created as resources
  6. Users, groups, roles are managed via the DMS
  7. When user needs to access specific resource stored in OWLIM, their access rights are computed by DMS and added as a context for the concrete request. In most cases this would mean that a list of named graphs the user has access to, will be sent with the request. OWLIM should limit its response to the listed named graphs.
    • Resources vs Documents
      Nuxeo DM functionality is built around the Document concept. Basically, most things the user works with, are documents - folders, blogs, forums, images etc. Workflows, version tracking and access control are applied on documents.
      OWLIM, on the other hand, operates on resources and their relations. We need to be able to "translate" or map these two concepts - documents and resources.
      Here is how we do this:
  8. We will introduce new document types in DMS that correspond to RDF types. They will server two purposes. First, this will allow standard actions on the resources - add to folder, for example. Secondly, they will be an entry point from the GUI to the RDF data graph. For now we need such an entry point for Museum Objects. These documents are just shells for the RDF data.
  9. As all the search methods would be implemented in the OWLIM, we need all the searchable data to be a part of the data graph. This basically means that every document in Nuxeo should be present in the RDF repository.
  10. Changes on the data are always initiated by its owner component and are replicated to the other side. Museum Objects are managed by RDF repository and documents are managed by DMS.
  • DMS - Browser
    As in any standard Web application, DMS will be responsible for handling user requests and providing the relevant response to be shown in browser.
    Additionally, there will be some substantial logic code in JavaScript and executed by browser. When large volumes of data are to be exchanged between the JS layer and the DMS, this will be done using JSON format.
    Ajax will be used to achieve responsive GUI.
  • IIP Image Server - Browser
    IIP protocol would be used to request tiles in view area.
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.