Jun 15, 12:26 PM
In one tweet, from @OpenRepository:
“Technology take away from #OR2015 is the Hydra-Fedora 4 stack is shaping up to be very impressive; plus ambitious plans from #DSpace camp”
Looking Back, Moving Forward: DSpace Roadmap
The theme of Open Repositories 2015 was “Looking back, moving forward.” The announcement of the DSpace Roadmap during OR2015 was timed to fit this theme.
DSpace development is going to change in 2015. DSpace 6 will be the last “bring us what you have” release, DSpace 7 and all future releases will be “managed” development. Put simply, if you want to have a voice in the technical future of DSpace, be ready to commit developer resources to an upcoming sprint. It’s a big change, but the community has determined this is the way development for DSpace must proceed if we are to meet our goals.
Of course, with DSpace 7 and onwards, pull requests will still be welcome. But the major feature development will need to be done as a community, in sprints. It would probably be helpful to think less in terms of “losing” a developer and more in terms of “gaining an entire team of developers” to work on a set of features that are important to your institution.
Two observations: 1) The Fedora Commons project has already successfully used this model in the Fedora Futures/Fedora 4 platform. 2) There is a leadership opportunity available to us… if we commit resources early in the process. Hesitation at this point sends a signal to the entire community. Even if we do eventually commit developer resources, hesitating to consider now may have an impact on the availability of other developer resources.
The Road Map is still a work in progress, there is an opportunity to ask questions or submit your feedback … Or just use the hashtag #dspaceplan on Twitter.
Portland Common Data Model
The Portland Common Data Model was presented during OR2015, and it fits in well with many ongoing conversations: not only between the various Fedora-based repository and digital library platforms, but also is immediately applicaple to an aspect of the DSpace Roadmap. I would be very surprised if the DSpace developers elect to use anything else for a data model. A great deal of thought has gone into crafting the Portland Common Data Model, and it specifically deals with the concerns outlined by the DSpace Roadmap.
We All Have ORCID Integrations, Now What?
Video of session I am glad to have participated, and I learned a lot by hearing how other repository platforms are handling the many use cases that a common identifier makes possible. Fair warning, if you watch this video, be prepared to hear me say “um” way more than ought to be humanly possible. To be fair to myself, this session was in the afternoon, in the middle of my one big day at OR15 (pretty much all my public speaking happened on that day). You can see me nod off a bit from time to time. Heh. Sorry.
DSpace Next Generation Workflow Workshop
This was a really interesting session, which consisted mostly of developers and repository managers splitting up into groups and talking about our experiences with DSpace workflows, how we’re using them, what we all like and what we’d like to see in a future offering of DSpace. These conversations resulted in the addition of a few use cases to the DSpace Use Cases document, as well as the discovery of a few existing tools.
The Harvard MyDASH usage statistics portal contains a workflow dashboard.
MyDASH is already on our list of things to look at more closely (Missouri folks, see MDPC#37). This might just bump it a bit higher on our list of priorities.
Dryad has a nice write-up on workflows and how they use them .
Dryad also has a “workflow dashboard” which was built by @mire, and it could be moved to standard DSpace quite easily (note it depends on the “customizable workflow” not the “standard workflow”).
I found myself volunteering to participate in the Ideas Challenge (the replacement for the Developer’s Challenge this year). My fellow team members were: Azhar Hussain (Nottingham), Joseph Rhoads (Brown), Kim Shepherd (Auckland), and Richard Jones (Cottage Labs). We called our idea “the Stuffinator”, and it took 2nd place in the challenge.
Here are the slides for our pitch.
And here are the announcements of all the winning entries:
Congratulations to all the winners, it was a really fun time, I will definitely aspire to participating again, and am grateful for the experience in participating this year.
Vagrant-DSpace live demo
There was no recording of this live demo, but I have notes from it, and it seemed well-received. I’m in the process of pitching the idea of a DuraSpace Hot Topics webinar, with demos of several Vagrant-based work environments for various repository platforms (everyone has one, except ePrints). Even if the webinar idea does not come to fruition, I intend to produce a screencast of the demo.
Digital Preservation the Hard Way
My poster submission, Digital Preservation the Hard Way, drew many visitors at the poster reception, and was also mentioned during one of the sessions about digital preservation. If it nudges someone in the right direction, or at least sparks a conversation that “disaster recovery” is not sufficient for digital preservation, I will be happy.
Stuff to check out later
Here’s my list of URLs I scribbled down, with some notes.
Kim Shepherd was singing the praises of Atlassian’s Sourcetree application, which is a GUI for Git. Kim says it’s helpful for visualizing branch mangement, and keeping track of what commits are in which brach, and where they came from. SourceTree is only for Windows and Mac. There are similar open source Git GUIs, the one that looks most promising is GitEye from CollabNet. It has been a while since I’ve played with a GUI with Git, it may be time to explore again.
Mentioned during Kaitlin Thaney’s keynote at OR2015, the sound bite is: “DOIs for code.” I don’t think this is the kind of code I write, it more for researchers to share, in addition to their data sets. It’s good to know it exists as a tool, especially as interest in automatic data set publishing grows. Having a tool to also automatically create links to the code necessary to process and undertand those data sets will be essential.
Working towards a common visual language for indicating a project follows open practices. It would be good to let our researchers know about these, as we interact with them.
An exciting effort to organize skill-sharing meet-ups of like-minded developers and others interested in learning more about developing software. It would be worth participating in this effort.
A messaging protocol, in the same category as SOAP, which is performant and supports caching.
An effort at making querying and using Linked Data more performant.
A content reporting add-on for DSpace.
Several developers brought up Slack in the context of improving communication. It looks like a nice tool, it’s free, we should probably play with it.
Richard Rodgers from MIT mentioned this project, and there are some references to it here: http://wiki.code4lib.org/NECode4lib_2015_Home
“a web application to allow users to discover, subscribe to, and obtain automatic delivery of article content from the SCOAP3 repository”
It sounds pretty cool: subscribe and have content delivered directly to your repository, via its SWORD interface. It’s not a service yet, but Richard tells me they hope to make it a service. Keep an eye on this.
A nice body of work up on GitHub. If one were looking for a reason to play more with Python, tinkering with these tools would be a great excuse.
Oh, and they are hiring, if you apply, tell them I sent you.
UPDATE 1: Kim Shepherd nudges me to acknowledge that we kinda/sorta really want to build “the Stuffinator.” And, I do think SEASR might provide a nice basis for such a tool. If you’re reading this and thinking, “Hey, I know SEASR, I want to play, too.” Get in touch. A tweet to anyone on our team would work.
UPDATE 2: Conference videos are starting to get posted. Right now it’s just the keynotes, but more will come. Keep an eye on that page.