Versions Compared

Old Version 25

changes.mady.by.user E. Lynette Rayle

Saved on

compared with

New Version 26

changes.mady.by.user E. Lynette Rayle

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of Contents

Table of Contents

...

Image RemovedImage AddedImage RemovedImage Added
full sizefull size

Planned Stack

  • Infrastructure – SHARED — code that can be shared by all universities
    •  RDF Models for Triples:  RDF Model classes and RDF Vocabularies (beyond those defined in ruby-rdf/rdf/lib/rdf/vocab) are defined in a local Ruby on Rails app.  
      •  Developing with Ruby:  2.1.2
      •  Developing with Rails:  4.1.1
      •  Gems:  Active-Triples
        •  The RDF Model classes extend the Resource class defined in the Active-Triples gem.
        •  NOTE: Active-Triples brings in code from several other projects.  I’m not sure of the full list, but ruby-rdf/rdf is certainly used by Active-Triples.
    •  SOLR Index
      •  Triples will be set up to go to a SOLR index using code currently in or soon to be developed code in Active-Triples gem.  I know there is some SOLR support, but I don’t know how extensive it is.  For example, we will want to put some information in our SOLR index that isn’t going into the triplestore and may need to expand the code to accomplish this.
      •  UI will query the SOLR index to retrieve data to display on the screen
    •  Triplestore
      •  I am currently developing over a simple triplestore in sqlite3.  We will be moving the final version to a fuller featured triplestore long term.  The triplestore is configured as part of the ActiveTriple gem and should not be difficult to move to a different triplestore system.  At this point, it is envisioned that this will be a standalone triple store that is separate from the main library catalog triplestore that will be created through the conversion process.   
  •  Infrastructure – Potentially Shared – code that may be able to be shared by all universities
    •  Conversion of university id (e.g. Cornell netid) into a VIVO URI.  Each university may need to write this utility for their IDs with a conversion to the URI of choice for that university.
  •  User Interface — NOT SHARED — all that follows is Cornell specific
    •  Authentication Code
      •  For Cornell, we will connect into our Shibboleth login system for authentication.
    •  UI based on mockups in the wiki will be integrating the infrastructure code into the Cornell catalog system which is implemented over backlight.

...