Page History

...

Planning | Description | Requirements | UI Mockup | Triples Examples | Queries Examples

...

Table of Contents

...

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.

...

Status of Sprints

Ok, best laid plans of mice and men.  Implementation is not following this plan.  Here are where things are currently...

• Infrastructure – SHARED
  
  • RDF models and vocabularies are 90% complete, but need a little more testing and perhaps tweaking.
    • 90% - models and vocabularies are complete and base ad-hoc testing in rails console
    • 80% - models are documented in Triples Examples wiki page to facilitate conversations with ontology group
      • outstanding issues
        • owner, contributors - Need to look into PROV ontology (per suggestion from Paolo)
        • lists - There are still discussions about whether to represent lists as ORE or Collections.  I plan to wait until I am further along and know more about the implications for implementation for each model.
    • 25% - currently writing rspec tests for models.  The test for the first model is close to being complete, but not sure what issues will arise when it runs.  The others should be quick to write since they are going to be very similar to the tests for the first model.
      
  • SOLR index - not begun beyond glancing at the code in ActiveTriple that works with SOLR
    • 5% - need to explore ActiveTriple code specific to SOLR in more detail and play around to see if it can already do what we need
    • 80% - queris are documentd in Queries Examples wiki page to facilitate conversations with ontology group
      • Initially, these were defined as SPARQL queries, so they need to be rewritten as SOLR queries.
        
  •  Triplestore - currently using sqlite3
    • 5% - need to explore fuller featured triplestore (DEPENDENCY:  Prefer to wait and see what Rebecca decides to use for her work.)
• Infrastructure - Potentially Shared
  • 10% - I have information from Jim Blake about how to get the information from VIVO, but there isn't a utility supported by VIVO that provides the URI. 
    
  • 0% - Write a utility that converts a Cornell netid into a VIVO URI.
• User Interface – NOT SHARED
  • Authentication Code
    • 5% - I've spoken with folks about how Cornell does authentication and looked over code that is similar to what will need to be done.
  • UI
    
    • 20% - I have cornell-blacklight up and running and have identified several places where we will be inserting code.
      
      
• ActiveTriples development
  • I have been corresponding with Tom (the developer of ActiveTriples) to understand his vision, current needs for development.  Once I grok where things are, I can start to see if there are shortcomings that limit our goal of ActiveTriples being easy to use in a Hydra stack without Fedora.
  • On the practical side, I have been creating a reference guide for ActiveTriples as I learn how the code works.  There is very minimal doc at this point and I am having to read class and rspec code to figure out how things work.  A reference guide will be an extremely valuable tool for future developers.
    

Sprints

Sprint 1:  Add a single work from an individual work page to a single supported virtual collection named My Virtual Collection.

...

Sprint 2: Use ActiveTriples instead ActiveFedora

...