Committers Call 2011-06-27

Owned by Bill Branan
Jun 16, 2017
3 min read

Participants

Bess Sadler
Eddie Shin
Matt Zumwalt
Mike Stroming
Rick Johnson
Simon Lamb
Rich Garbutt
Julie Meloni
Molly Pickral

Agenda

  • Uploads – Paperclip? (Simon Lamb)
  • Hypatia EAD Modeling
  • Jettywrapper
  • Rails3 (wasn't any time for this)

Uploads – Paperclip? (Simon Lamb)

Simon:
File uploader discussion at Hull
Jon mentioned maybe using Paperclip as a good ruby gem uploader (includes ability to do multi-file upload), instead of using Flash

Eddie:
Discussion on this is needed, has anyone else used Paperclip or something other than Fluid/SWF Upload?

Matt:
Reason for using Fluid/SWF Upload is that SWF Upload makes it possible to select multiple files at once for upload
Should we get rid of this uploader?
Should we get rid of Flash?
Need to remember we need to be able to select multiple files at once for upload
Does anyone know if Paperclip lets you select multiple files at once?
Paperclip used to write to a db (3 years ago)
Has Paperclip evolved from this?
Sounds like we need to know more about Paperclip

Simon will be taking a look at it

Hypatia EAD Modeling

Rick:
Differences between Hypatia and Notre Dame
Hypatia converts EAD to MODS
ND leaving as EAD, converting to something that allows use of unnumbered components
Using RELS-EXT to maintain relationship
Not a whole lot of convergence of functionality between ND and Hypatia

Bess:
Hypatia will hopefully end up being able to manage the EAD's, but not very soon

Rick:
Plan on sharing the ingesting of EAD and breaking that up into different objects, Hypatia folks will be looking to use that
Rajesh will send this out when it's ready
Trying to see if Atrium can be more of a Blacklight plugin
Will hopefully not require ActiveFedora or Fedora

Spinoff discussion regarding APO needed

Matt - We're getting to a point where we're renaming limited set of Fedora specific relationships, Did anyone like Michael Klein's suggestion on the Freebase RDF?
Bess - Suggestion was a good compromise
From Michael Klein's email:
For example, here are some of the assertions from the Freebase RDF on Liv Tyler:
<rdf:RDF rdf:about="http://rdf.freebase.com/ns/en.liv_tyler"  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:fb="http://rdf.freebase.com/ns/">
<fb:people.person.gender rdf:resource="http://rdf.freebase.com/ns/en.female"/>        
<fb:people.person.parents rdf:resource="http://rdf.freebase.com/ns/en.bebe_buell"/>
<fb:people.person.parents rdf:resource="http://rdf.freebase.com/ns/en.steven_tyler"/>
<fb:people.person.profession rdf:resource="http://rdf.freebase.com/ns/en.actor"/>
<fb:people.person.profession rdf:resource="http://rdf.freebase.com/ns/en.model"/>
<fb:people.place_lived.location rdf:resource="http://rdf.freebase.com/ns/en.maine"/>
<fb:film.actor.film rdf:resource="http://rdf.freebase.com/ns/m.03d_jyz"/>
<fb:award.award_winner.awards_won rdf:resource="http://rdf.freebase.com/ns/m.0b458k1"/>
</rdf:RDF>
Every fb: assertion is dot-notated in three parts: domain, type, and property. We can visually and semantically separate her personal attributes and relationships (people.person.) from her attributes as an actor (film.actor.) and musician (music.artist.* and music.group.membership, which I didn't include).

Bess - Would anything be messed up if people use different relationship names?
Eddie - It would be useful to have a best practice convention, Hydra recommended practice, Decision needed ASAP
Matt - Let's make a decision that's as simple as possible, document why decision was made
Eddie - Maybe we should use Michael Klein's suggestion
Matt - The discussion might create a new round of discussion that we don't have time for
Bess - We could just start coding version 0.1 and let them keep having the discussions
Eddie - Like's that suggestion
Rick - Sounds good
Matt - We probably shouldn't introduce Freebase when we propose 0.1 (too much of a change from previous dicussions), might work for 0.2
Eddie - That sounds good

Rick and Eddie will talk

Bess:  In general, try it out before you declare it won't work
Eddie:  Less talk, more code

Jettywrapper

Bess:
Very close, but build is still failing
Integration tests are passing on local, but not on server, saying it can't kill processes it started

Matt:
Sunspot as a possible option? https://github.com/outoftime/sunspot/tree/master/sunspot/lib/sunspot

Bess:
Works, but just doesn't shut down jetty sometimes. This is for dev and test, not production.  How much of an issue is this?

Matt:
Worst case scenario is that builds will fail because of another previous build not shutting down cleanly because of jetty not shutting down

Eddie:
Does jetty-wrapper fail to build if it fails to shut down correctly?

Bess:
If the process that launched jetty ends, then jetty ends (fork off of a Ruby process)

Eddie:
Not a production issue, let's move on

Bess:
Need to start working on something else

Two copies of hydra-jetty (test and production)

Two submodules in git?

Should git submodule update pulls down test or dev?

Rick: As long as it's automated, it doesn't matter

Matt: Bess, can you throw on ticket on JIRA so someone else might be able to work on it?

Matt: This call has become more of a community/partners call, would like this call to be the committer's call again, a community call will need other people
These are the tickets for the committer's call on Tuesday https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+HYDRA+AND+fixVersion+%3D+%22weekly+sprint+for+June+28%22+ORDER+BY+status+DESC%2C+priority+DESC

Note taker for next call (July 11th): Julie