Attendees
Jonathan Corson-Rikert
Brian Caruso
Brian Lowe
Jim Blake
Jonathan Markow
Andrew Woods
Call-in Details
Call-in toll-free number (US/Canada): 1-855-244-8681
Call-in toll number (US/Canada): 1-650-479-3207
Access code: 646 242 414
Agenda
- Identifying the technical tasks required to bring a new implementation of the vivosearch.org prototype online as a cloud service
- Estimate the developer resources and time required
Discussion
Wiki updates
- Brian has done some wiki gardening
- Moved content from other space into VIVOSearch
Goals and Approach Review
wiki page
- Review in light of stages/phases
- If we do the same thing as before, users will notice disambiguation issues
- How to resolve the disambiguation issue?
- Come up with a community approach
- Rely on partner organizations to map URLs of the same user
- Last VIVO management meeting...
- VIVOSearch is promising, but involves considerable work to get there
- This will need to be explained to people
- Existing VIVOSearch should be considered a prototype
- This communication could encourage CTSAs to contribute
- Need to create estimates of what effort will take to get to first phase
- Indicate what functionality falls into each phase
- Features of search
- full text - yes
- semantic - future
- faceted - yes
- complex queries - future
- people - yes
- publications, organizations, etc - yes
- Description of approach
- Approach to building index
- Same as what is currently in place
- Current VIVO does not have a direct way to get institutional URIs
- VIVO used to get RDF for each URI, then make subsequent requests as needed
- Can investigate new approaches
- Policy questions
- How much data do we want to get from each resource (e.g. people)
- This is the kind of thing that needs to be asked of the institutions
- Suggestion to collect these tasks in a spreadsheet
- Include time estimates, and outstanding questions
- How to determine when external resources have changed
- Keeping the index up-to-date
- Hope is that the approach is same as building the index, with different input
- Alternatives
- Possibly can raise with broader community
- Technology choices
- HTTP for retrieving RDF, yes
- What is the adoption of SPARQL in the community
- It may be nice to demonstrate that a SPARQL endpoint is not needed to enable interesting results
- Solr, seems reasonable for now
- Considering having Solr in one place versus distributed Solr (master/slaves)
- Web interface: drupal with solrsearch.js
- Most work is on clientside with js
- This continues to be appealing
- We have limited insight into this component
- Suggestion to create list of default technologies, criteria, and alternatives
- Hadoop is currently reasonable choice
- Ruby (blacklight/hydra) or Drupal?
- The js pattern allows from minimal reliance on Drupal
- Need a mock-up of the UI to inform design of solr index
- BootStrap is an interesting js framework to consider
- Drupal upgrade cycle can be onerous
Tasks Review
wiki page
- Brian Caruso has limited available in 2 week windows
- Need to clearly define what goes into phase 1
- Request to create comprehensive planning spreadsheet
- Column for time estimates, phase, issues, etc
- Need to meet more regularly
Next steps
- ...