Note: This work led to the implementation of Hyra Works, Hydra PCDM, and eventually the Hyrax solution bundle. For the finished data model, see Hydra Works Data Model.
Hydra::Works is a flexible, extensible domain model that is intended to underlie a wide array of Hydra repository applications in order to facilitate collaboration across projects. Hydra::Works emerged from a discussion at Hydra Connect 2 in a session about the various community solutions to institutional repository-like applications – such as Sufia, Worthwhile, Curate, and Hydrus, and including some non-IR-like apps like Avalon – during which we learned that there was broad interest in an IR-like solution bundle that combined the best features available in these applications (see notes from that session).
The first step towards building this solution bundle was to come up with a domain model that is designed to work for use cases across these distinct approaches. A follow-up discussion was held during the October 8th Hydra Tech call and it was decided to create a GitHub repository which is holding most of the discussion so far (deliverables from GitHub will ultimately live on this wiki). We are gathering use cases until October 22nd for the first phase of development, so please see here for sample use cases. If that timeline doesn't suit your needs, there will be opportunities to get involved later – like most of our work, we will continue to iterate upon and improve Hydra::Works over time.
After we've reviewed the initial use cases, development can begin on an alpha version of Hydra::Works. The actual merger of Sufia and Worthwhile can take place between Q1 and Q3 of 2015, which was the timeline that most of the attendees of the Sufia Futures discussion at Hydra Connect felt best able to work within.
The process for the alpha version of Hydra:Works will be to build a base model prototype that will cover two base use cases:
See gist: https://gist.github.com/jeremyf/4ac46163af876673e5a7
https://github.com/projecthydra-labs/hydra-works/tree/hydra-works-interface
An application profile will also be created as a human readable schema to be used as a data dictionary.
See gist:
See here for the work in progress: Hydra::Works
A GenericWork is an intellectual entity, sometimes called a "work", "digital object", etc., with the following attributes:
A GenericFile is a sequence of binary data, with the following attributes:
A GenericCollection is a group of GenericWork records:
See also User Collections, Admin Sets, Display Sets and Further thinking on Collections, Sets & Lists for more description of different types of collections with differing rules for duplicate entries, ordering, etc.
A review of the use cases submitted as issues or pull requests to the Hydra::Works Github repository found that virtually all use cases were compatible with the consensus model, and fell into a few basic scenarios:
Works with differing levels of component structure
Works without components
Structure
Work (with optional file(s))
Examples
#14 User-contributed work
Works with a single level of components
Structure
Work (with optional file(s))
Component (with optional file(s))
Examples
#8 CD with tracks
Newspaper with articles
#9, #10, #22 Book with pages
#23 Photograph with front/back
poster, postcard with front/back
Works with a multi-level hierarchy of components
Structure
Work (with optional file(s))
Component (with optional file(s))
Component (with optional file(s))
etc.
Examples
#11 Research dataset
#23c Book set or multi-part manuscript
#23d Photo album
#29 Event
Collections of Works with differing notions of collection order and membership
Unordered sets
Structure: Works are unordered, and may only appear once
Examples: #17 Playlist, bookmark list
Ordered lists
Structure: Works are ordered, and may appear more than once
Examples: #18, #26 User collections
Admin sets
Variation of unordered set where each Work is required to belong to exactly one admin set.
In addition to these patterns, there are also a few variations that apply across the different structures:
Constraints
Number of children may be constrained (e.g., a Work representing a postcard, coin, etc. may allow at most two Components).
Works may be required to have exactly one of a certain kind of collection (i.e., Admin set).
Ordering
Contained items (Components within Work/Component, File within Work/Component) may have a single order denoted by a sort property (e.g. mods:partNumber).
Any item that contains or links to other items (Collections linking to Works, Works/Components containing Components/Files) may have any number of additional ordering schemes.
Collections may have links to Files (e.g., thumbnail)
Works may contain other works (e.g. certain kinds of events/exhibitions/etc.) – probably linked and defined in relations rather than the Work containing other Works.