This wiki space is deprecated

This wiki space is now deprecated. The wiki for Samvera (formerly the Hydra Project) is now to be found here: Samvera

Skip to end of metadata
Go to start of metadata

Dates and Location: February 3-5th at UC San Diego Library, Geisel Building.

Room: Seuss Room (see map below)

Wednesday - 3rd

  • 8:30-9:00 Light Breakfast (coffee, tea, pastries)
  • 9:00-9:30 Welcome, Introductions, High-Level Schedule (check on folks’s departure plans)
  • 9:30-10:00    Folks Pitch Development Ideas - 2 minutes to describe Scope, Benefit, Outcomes
  • 10:00-10:30 Team estimating - for each idea, give a score for each of
    • Clear acceptance criteria
    • Time to complete
    • Benefit / Value 
    • Right people present to work on it
  • 10:30-10:45 Group into teams of 4-8
    • sort list for highest scoring ideas (It has clear scope, high community value, and can achieve MVP in 3 days)
    • nominate a “Product Owner” for each team - someone to break design deadlocks and keep things moving
  • 10:45-11:00 Break
  • 11:00 -12:30  Develop in teams
  • 12:30-1:45-ish Lunch
  • Afternoon - Tracks
  • 5:00-5:30 Report backs - what we did, what we hope to do tomorrow, things we think might hinder us
  • 5:30 Pizza at Round Table

Thursday - 4th

  • 8:30-9:00 Light Breakfast (coffee, tea, pastries)
  • 9:00 Local announcements (review schedule for the rest of the day)
  • 9:00-12:00  Develop in teams
    • (optional) 11:00-12:00  Help Mark brainstorm Training - what’s going well, what’s missing, how do we get there?
  • 12:00-1:00  Lunch
  • 1:00-4:00  Develop in teams
  • 4:00-4:30  Daily report out
  • 4:30 Organize for evening

Friday - 5th

  • 8:30-9:00 Light Breakfast (coffee, tea, pastries)
  • 9:00-11:00  Develop in teams - prep for demos
  • 11::30-12:00  Final Dev Team report outs & demos
  • 12:00-1:00  Lunch
  • 1:00-4:00  open development/work time


DayDesign PrinciplesLOD+Performance IssuesGemificationCloud & VM
Wednesday
Afternoon 

#2 Collection Permissions

(Rayle) 

#21 IIIF from Plum–>CC
#27 Proxy stack
(Sanderson, Cowles) 

#1 Gemify SHARE
(Wead) 

#26 AWS Services
(Beer) 

Thursday
Morning 

#9 Configurable Metadata
(Rayle) 

#3 Hydra/Fedora Contract
(Woods)

#22 Access Control API
(Bussey) 

#4 & #19 Gemify a Concern
(Pendragon) (https://github.com/projecthydra-labs/book_concerns)
#26 AWS Services
(Beer) 
Thursday
Afternoon 

#10 Workflow State Modeling
(Friesen)

 #4 & #19 Gemify a Concern
(Pendragon) 

#26 AWS Services
(Beer) 

Friday
Morning 

#11 Admin for Users & User rights
(Rayle) 
#18 PCDM Perfomance Issues
(Needs Owner - formerly Bussey) 
#15 LOD Caching
(Bussey)  

#5 Browse Everything–>CC
(Wead)

#13 HydraCamp VM
(Bussey)

#26 AWS Services
(Beer) 

Friday
Afternoon 
  #8 Promote curation_concerns
to project hydra main repo
(Coyne) 

#13 HydraCamp VM
(Bussey)

#26 AWS Services

(Beer) 
Unscheduled

#6 Mint new Hydra gem - 3 votes

#7 Hydra on Solr 5 - 2 votes

#16 Enhance QA autosuggest behavior - withdrawn

#17 QA autosuggest disambiguation fields - withdrawn

#20 Containerized Hydra - withdrawn in favor of #26

#23 CSV Import into Sufia - 9 votes (needs developer and product owner - contention for Coyne/Bussey time)

#24 Roadmap for ActiveTriples 1.0 - 5 votes (lunch/dinner discussion?)

#25 ActiveFedora changieret refactor - 2 votes

 


 

Walking directions from hotel to Geisel Library building:

There is also a pedestrian bridge over La Jolla Village Drive that can be used to avoid the intersection with Villa La Jolla: Google Maps walking directions.

Directions from Geisel Library building lobby to Seuss Room:

Lodging: Sheraton Hotel Reservation Page

Attendees (limit 30)

  1. Adam Wead (PSU)

  2. Vivian Chu (UCSD)

  3. Trey Pendragon (Princeton)

  4. Mike Giarlo (Stanford)

  5. Justin Coyne (DCE)

  6. Jeremy Friesen (Notre Dame)

  7. Huawei Weng (UCSD)

  8. Esme Cowles (Princeton)

  9. David Trujillo (UCSD) 

  10. Mark Bussey (DCE)

  11. Glen Horton (Cincinnati)
  12. Andrew Woods (DuraSpace)
  13. Matthew Barnett (University of Alberta)
  14. Jon Stroop (Princeton)
  15. Joe Atzberger (Stanford)
  16. Ryan Wick (OSU / Oregon Digital)
  17. Thomas Scherz (Cincinnati)
  18. Aaron Coburn (Amherst) 
  19. Mark Matienzo (DPLA)
  20. Lynette Rayle (Cornell)
  21. Daniel Pierce (Indiana)
  22. P. Kieran Etienne (WUSTL)
  23. Audrey Altman (DPLA)
  24. Rob Sanderson (Stanford)
  25. Tom Johnson (DPLA)
  26. Chris Beer (Stanford)
  27. Erin Fahy (Stanford)
  28. FULL!

Goals

  • Focused face to face time for Hydra developer community
  • Community code exchange
  • Move community development goals forward
  • Escape winter for 3 days in San Diego

Development Ideas

  1. SHARE Notify gem: Penn State is just about finished implementing a mechanism to publish files from Scholarsphere into SHARE Notify. It could make a good gem if others are interested in doing the same with their Sufia or Hydra-based apps. (Adam Wead)
  2. Develop implementation plan for collection permissions and/or user collections, admin sets, and display sets.  I'd like to get this nailed down enough that we can come away from HDC with an implementation plan.  Cornell has a project that needs this on the near horizon and I have cycles to work on implementation starting in Feb. (Lynette Rayle)
  3. Hydra/Fedora positioning: what is the desired line of responsibility between the two and necessary implementation changes (if any). (Andrew Woods) 
    1. Potentially related: identify necessary, high-priority Fedora updates and/or fixes.
  4. "Book Concerns" - how best to wrap up an additional layer of assumptions on Curation Concerns for sharing. Things like IIIF concerns to be used for books. (Trey Pendragon)
  5. Add Browse Everything functionality to Curation Concerns. (Trey Pendragon)
    1. And remove from Sufia (or base Sufia's impl of browse-everything on CC's) – let's not do the same thing in two places if we don't need to.
  6. Build a new version of the "hydra" gem and test "Dive into Hydra" with it. There was a 9.1.0.rc1 last April, but that's the last time anyone touched it. 2-3 hrs (Justin Coyne)  If this is for PCDM, test "Dive into Hydra-Works".  When is it time for Dive into Hydra-Works to replace Dive into Hydra?  Write a test suite for Hydra:Works that covers the Dive into Hydra-Works tutorial. (Lynette Rayle)
  7. Run Hydra on Solr 5. This means replacing jettywrapper with solr_wrapper and fcrepo_wrapper (https://github.com/cbeer/fcrepo_wrapper). 4 hrs (Justin Coyne)
  8. Promote CurationConcerns to projecthydra (from labs). 2 hrs (Justin Coyne)
  9. Flexible metadata handling where additional fields can be applied to all collections, specific collections, or based on resource. 4 hrs. (Lynette Rayle)
  10. Formal workflow support including workflow states with users assigned roles that allow them to operate on resources in a given state, ability to move forward and back between workflow states, and control over release dates of resources. 4 hrs. (Jeremy Friesen)
  11. Admin functionality for managing users (e.g. blocking/deleting users, resetting passwords), user roles and privileges, managing collections and works  at the repository level and collection level (e.g. super-admin can view/edit/delete all collections; collection admin can grant privileges to users for that collection; super-admin can view/edit/delete all works; collection admin can view/edit/delete works within a collection). Outcomes: list top 3 things that could be done. (no timeframe listed)  (Lynette Rayle)
  12. Review Sufia UI WG's new wireframes for Sufia 7, especially of interest to Sufia and CurationConcerns developers and users (Lynette Rayle, David Trujillo, Mike Giarlo)
  13. Build a new HydraCamp VM, decide what tutorials it should support. < 1 day (Mark Bussey)
  14. Extract mediated deposit and workflow from HyHull (video demo here) for potential integration into Sufia or curation_concerns based heads - possibly merge with #10. 2-3 days for proof-of-concept (Mark Bussey)
  15. Background caching / cache warming for remote authorities --> marmotta.  (Mark Bussey)
  16. Better auto-suggest behavior for questioning authority for authorities with large vocabularies (i.e. LACNAF, LCSH). 1.5 days (Mark Bussey)
  17. Configurable auto-suggest disambiguation for questioning_authority (i.e. specify second term to show for disambiguation). < 1 day (Mark Bussey)
  18. Performance tune adding items to PCDM containers with many objects, esp. ordered sets. (Mark Bussey) - problem: we're seeing potential performance issues ingesting multiple objects and/or large collections. 4 hrs.
  19. "Media Concerns" - can we come up with a basic reference model for curation_concerns for video and audio that can be augmented as needed for specific use cases? Similar to #4 (Mark Bussey)
  20. "On-demand" cloud instances to support dive-into-hydra or other tutorials - Dockerize Hydra? this might be crazy talk... (Mark Bussey)
  21. Extract IIIF-generating functionality from Plum and move to CurationConcerns. Outcome: moving code, agreeing on mapping. 1 Day. (Esmé Cowles)
    1. And agree on, document PCDM / IIIF mapping (Rob Sanderson)
  22. API for external services to consume "Access Controls" from Hydra based repos. Outcome: design doc. 4 hrs. (Mark Bussey)
  23. CSV importer for Sufia (Mark Bussey)
  24. Roadmap for ActiveTriples 1.0. 2 hrs. (Tom Johnson)
  25. ActiveFedora Changeset Refactor (Tom Johnson)
  26. Deploying Blacklight / Hydra / fcrepo4 to AWS (using AWS services) (CloudSearch, RDS, etc) (Chris Beer)
  27. Discuss Princeton's Proxy of Proxy of Proxy of ... stack, the issue that this addresses and how to solve it consistently. Outcome: find why it was done and what the possible solutions might be. 2 hrs. (Rob Sanderson, Trey Pendragon)

Outcome: find why it was done and what the possible solutions might be. 2 hrs.Other Topics

  1. A brief tutorial on the internal workings of HydraHead, ActiveFedora and/or Blacklight to get more developers familiar with the core gems. (suggested by Esmé Cowles)
  2. Promote CurationConcerns from the projecthydra-labs Github organization to projecthydra (and review the contributing guidelines to make sure they are relevant) (Esmé Cowles)
    1. Also, how about:
      1. active_fedora-noid
      2. activefedora-aggregation
      3. hydra-works
      4. hydra-pcdm

 

Development Ideas, Prioritized (for later use, pls do not edit)

SessionShort NameInterest CountRankWell DefinedAchievable by FridayFeature/Description
1SHARE Notify4   

 

2Collection Permissions10    
3Hydra / Fedora Positioning10    
4Book Concerns11    
5Browse Everything8    
6New Hydra Gem3    
7Hydra on Solr 52    
8CurationConcerns Promotion4    
9Flexible Metadata Handling9    
10Workflow Support6    
11Admin Functionality5    
12Review Sufia UI Wireframes8    
13HydraCamp VM6    
14Extract Mediated Deposit(dependency)    
15Background Caching -> Marmotta8    
16Better Auto-suggestscrap    
17Configurable Auto-suggestscrap    
18Performance Tune PCDM Containers15    
19Media Concernsrolled into #?    
20On-demand cloud instancesscrap    
21Extract IIIF from Plum9    
22API for External Access Controls5    
23CSV Importer for Sufia9    
24Roadmap for ActiveTriples5    
25ActiveFedora Changeset Refactor2    
26Developing Hydra for AWS8    
27Princeton's Proxy, Proxy, Proxy9    

 

Events

February 3rd Dinner/Reception

  • Location: Round Table Pizza
  • Time: 5:30pm
  • Details: Pizza (meat and vegetarian) and salads will be provided. Drinks are on you.

February 4th Beer Crawl

  • Location: We will coordinate at the Library and head to 30th Street in North Park via a combination of carpools and Uber/taxi/public transit to be determined.
  • Time: 5:00pm
  • Details: We will visit a few of Matt and Declan's favorites, with plenty of food options along the way. Everyone will be free to branch off and/or head home as needed.

Other UCSD Events and Information

 

 

5 Comments

  1. Lynette Rayle The 'hydra' gem is not for hydra-works.  Hydra-Works is one level of abstraction on top of the 'hydra' gem.  I think "Dive into hydra" should continue to be maintained and that "Dive into Hydra-Works" should be a lesson you do after you do "Dive into Hydra".

  2. Justin Coyne There is a lot of overlap and similarities between the two tutorials.  Dive into Hydra-Works follows the same lessons and steps as Dive into Hydra, albeit using the syntax and API of PCDM and Hydra:Works.  Michael J. Giarlo suggested to me that Dive into Hydra-Works might be a replacement of Dive into Hydra.  Perhaps the way to frame the discussion is whether the two tutorials should stay separate, how they relate and interact, and what each should cover in their lessons.

  3. Lynette Rayle Justin Coyne:

    Yes, this is ultimately a training question, and a familiar one: how soon after a seachange should our training and tutorials reflect the most recent practices? See: RDF metadata, Fedora 4, and the PCDM stack. I suspect we'll want folks like Mark Bussey and Bess Sadler (who have been go-to people for training over the years) involved in this broader conversation.

  4. "how soon after a seachange should our training and tutorials reflect the most recent practices"

    1. Not until the sea changes are stable enough that they aren't going to frustrate newcomers (i.e. we taught you this way last week, but we changed our minds and the code now works this way...)
    2. Not until there's a strong enough base of existing developers in the community willing to help newcomers with the new way of doing things - i.e. we need maybe 4-8 seasoned developers who feel comfortable with the new practices and are willing to make themselves available on e-mail and IRC when newcomers run into problems
    3. As soon as practical after that.

    If we think of "Dive into Hydra" as the entry point for new developers in the community to get started, then I think it should reflect the practices they'd see in a 'contemporary' hydra head.  I think that means we want it to incorporate PCDM pretty soon - once we think my first two criteria are met.

    In terms of maintaining both versions of the tutorial, when would we generally suggest that someone not use PCDM?  That should be the use case and examples that a non-PCDM tutorial focuses on.  It's confusing (and time consuming) to show newcomers two ways of doing things without helping them understand why they'd choose one or the other.  We show both XML and RDF based modeling in Dive-into-Hydra right now because we know there are institutions in the community using both - the tutorial explicitly says to skip the steps if you don't use one or the other.  It's a pain keeping those two in sync, but I think it sill has enough value to do based on actual use cases in the community.  I would do the same evaluation on PCDM vs. non-PCDM object modeling.

  5. My thinking is the people will want to learn the basics (plain old hydra) before we try to throw hydra-works at them.  We really need a stable release of Hydra 9. I don't think we have a Fedora 4 stable hydra release yet.  Since, hydra-works is beta, we shouldn't put that in this version.