Hydra Connect 2

Sufia Futures Working Group

10/3/14 (1:30 pm)

29-30 people in the audience

Notes taken by Linda Newman

Mike stated the purpose of this meeting was in part to clarify a common vision about the community desires for Sufia priorities and the Penn State priorities.

survey indicated that people chiefly wanted 1) work not file-centric approach and 2) mediated deposit, and 3) administrative/reviewer dashboard.

related work in Worthwhile — already some implementation out there

other possible related development priorities

collections within collections

child objects and parent objects

history of sufia, curate, worthwhile, hydramata

sufia was written first

sufia models was extracted from sufia and used in curate

worthwhile is a pared down version of curate

Justin from DCE has created something like a worthwhile 'works'

If this becomes Hydra Works Sufia can use it

Sufia and Worthwhile will merge one way or another with maybe a difference only in the UI that you want.

Big data – is that a priority and what is application support

Question about hydra derivatives and how it is used

multiple files are put into the same datastream/object and then attached to the one work – the public is shown the derivative not the master

Priorities placed on the whiteboard:

1) Works /workflow/dashboard

2) (Fedora4?) Big data

3) Administrative collections

"APO's"

faceted discovery

4) Modularity (gemification)

Discussion of Works in the Core Committers group: Rick Johnson reported that there was motivation to figure out common patterns and have the result be an extraction and common code. Penn State, DCE, UCSD, Stanford, NW, IU, ND, and possible others interested in working on this. Starting with what's in Worthwhile, do a gap analysis. There will be a HydraWorks working group that we could route use cases to.

Base model – files belong to works. A work can have many files or one or zero. A file has to have a work. A file can only belong to one work – some controversy but not something we need to resolve now. File is a generic file that could still be processed by Hydra derivatives and have multiple files in one datastream.

Does supplemental work or related works need to be in the model? Not the same as parent and child works?

Hydra Works and Hydra Collections remains separate.

Declan: Where do you draw the circle around the work?

(Venn diagrams on the white board:)

Now: Sufia contains Sufia-Models Gem. Worthwhile contains Works gem and Sufia-Models gem.

Future: Sufia/Worthwhile both contain Hydra-Works

Justin: Curate should be able to move to Sufia/Worthwhile containing Hydra-Works

Avalon might be able to use Hydra-Works

Does Sufia need to incorporate the atomic model being developed by UCSD? (Anusha made a point here that led to this discussion.) (Multiple files on an object rather than multiple files in a datastream.)

Tom said let's look at RDF expressions and make a formal expression of our model/specification, including files, works, collections, administrative sets and make it a recommended part of the Hydra Way.

Documentation of use cases needs to be the start. Is it reasonable to suggest that the Hydra Works using group take up soliciting user stories and documenting the data model per the lines that Tom suggested? General consensus on both these points.

Sufia Models and Hydra Works needs to be independent of Fedora 4, are we still in on track.

We don't want to make this an absolute data model – just a base model. Blocker should be that something is incompatible with the model, not that the model is not sufficient.

Timeframe – end of 2014 to have documented use stories and to have a proposal for a work oriented data model?

Use the development model used by Fedora 4? Institutions allocated both money and development resources – 1/2 developer per 6 month cycle with two week sprints. Andrew is product manager and technical lead.

Justin not sure that's a good proposal for this project – might be better just to have a small group of people work on it and throw it out for comment. Doing the design up front – not the implementation – is the major thing that needs to happen now. Having a pile of people won't help.

What design artifacts need completed first – data model, user stories, other?

Do we need a more fine-grained overview of models with examples/samples?

On whiteboard:

Design Artifacts for 2014 Hydra Works Working Group

User stories
Data model

+ sample/test data

2015:

3. "Processing pipeline"

4. Wireframes --> PSU & Stanford proposes these for community review

Do we need to scope it down a little bit – agree on a common data model – work on standardizing the implementations next.

Are 3 and 4 also needed before developing? Some thought that not necessary – this is only when trying to implement the Hydra Works gem into something like Sufia. But how to people evaluate the gem before understanding implementation? Is a 3rd policy scoping it into working on a particular Hydra stack (Hydrus, Sufia, Avalon) concurrently with development? How to make sure that the Hydra Works gem is generic? Extensible?

What would give us confidence that the design artifacts work for us? Is next step after design testing implementation?

Aspirations to have something – code written and deployed – by March 2015.

We may not agree on wireframes but will agree on actions that should happen.

Oxford – 2015

Curate at Notre Dame – launching in December campus wide – will have development capacity after the end of the year.

Avalon - Dec/Jan 2014

Cincinnati – interested in getting Curate interface on top of Hydra Works and/or switching to Sufia when it is using Hydra Works (and this may be an unclear distinction). Developer resources may be available by January.

Alberta – March they deliver first product

WGBH

Is this effort more than "Sufia Futures"

Browser not supported