- creator/manager permission
- 1 step
- mediated work flow
- public | private | institution
- visibility as policy
- students submitting DTD cannot embargo
- temporal permissions to materials
- work types
- one work type to do everything
- resource type
- submission tool to get stuff of a certain kind
- nested works - parent and child works
- filesets (vs. using nested works)
When to use nested works vs. nested collections vs. multiple filesets?
Examples for blocks:
How to use admin sets as policy objects
Types of Repositories
- purpose: is to collect research output of the university
- depositors: either deposited by content creator or by a designated group
- typical content:
- white papers
Digital or Managed Collections Repository -
- purpose: is to collect curated content
- depositors: smaller number of depositors, larger number of content
- typical content:
- digitized books
Multipurpose Institutional Repository
- purpose: support both types
- depositors: mix of self deposit and staff deposit
- typical content: mix
Designing for Use Cases (~1 hour)
Have a use case you are working with that you would like to explore? Add it here. A variety of use cases will be selected to serve as examples during the workshop. We will work through design possibilities and questions during the workshop in order to build a better understanding of the tools we have available to architect our repositories. We will select 4 uses cases to focus on and discuss 2 as separate systems and look at putting 2 in one system.
Approaches to System Design
- How items come into a system? May have multiple workflows to support many different purposes.
- 1 time users
- Fewer people (depositing works into) working with the system.
- More homogenous workflow.
Separate systems vs. one large system.
- Homogeneous Content
- Various of content
Potential Use Cases for Discussion
Use Case: Self-Deposit
In a self-deposit repository system, any user with a login can add works and files.
- As a logged in user, I want to create new works that are attributed to me and discoverable by the public.
- As a logged in user, I want to be able to organize my works for my own use.
- As a logged in user, I want to be able to organize works to share with others.
Use Case: Curated Exhibits
In a curated repository, select staff can create content and selectively release it for public consumption.
- As a librarian, I want to select public works to include in a curated exhibit.
Use Case: Mediated Deposit and ETDs
Example of Using Admin Sets & Collections in conjunction
- Admin set defines common workflow & visibility configs that effect all works in all collections (ETD workflow/visibility policy)
- Collections define permissions for groups/users to be able to see/deposit works in each collection (one collection per department defining the users that can view/deposit to each collection)
Use Case: Research Data Curation
Use Case: Migration from D-Space to Hyrax
There are many uses for D-Space. One use is the collection of faculty/staff research for a department on a university campus.
- As a repository manager, I want to create collections for each organizational unit of the university.
- As a faculty/staff member, I want to be able to create new works within my department's collection which are attributed to me.
Use Case: Art Institute of Chicago
Use Case: Journals & Volumes & Issues
Volume typically refers to the number of years the publication has been circulated, and issue refers to how many times that periodical has been published during that year.
Use Case: ... feel free to add another use case
Hands On Activity (~30)
Using your own use cases or ones we supply, design an approach and solution using the building blocks.
What's your biggest motivator on making customization decisions?
Questions to ask yourself to decide type of building block strategy you need...
- What types of users will work with your repository?
- do users play different roles in the repository?
- are there limits on who can create collections or certain kinds of collections?
- are there limits on who can create works?
- are there limits on which collections a user can add a work?
- are the users occasional/one time users or power users?
- What kind of content do you want to have in the repository?
- is the content homogeneous or varied?
- are the access control needs varied or homogeneous?
- What types of collections are needed beyond the predefined User Collections and Admin Sets?
- limits on who can create
- limits on discoverability (NOTE: can't control with an admin set)
- limits on other configurable settings (e.g. branding, nesting, sharing, membership restrictions, visibility restrictions, etc.)
- What admin set strategy is needed?
- multiple admin sets vs. just using the default
- do you need collection based permissions?
- one to one relationship between worktype and admin set? (customization)
- What workflow strategy is needed?
- always use same workflow?
- need multiple workflows?
- need custom workflow?
- What visibility strategy is needed?
- same visibility for all works?
- visibility policy based on legal access to works?
- visibility depending on type of work?
- What worktype strategy is needed?
- How many distinct worktypes do you need and what are they?
- Will everyone need to use them or should some people be able to use certain worktypes? (customization)
- Will worktypes be defined by user needs or metadata needs or both?
- Or deposit only to certain admin sets or collections? (customization)
- What relationship strategy is needed?
- Is nesting need?
- When will you use collections, parent/child, work/fileset relationships?
- Do you have metadata at the file level where child/nested works are needed or will you use filesets?
- How will performance be considered? (e.g. nested works vs filesets vs collections have different performance concerns)
- Do you need ordered relationships?
- What is your discoverability strategy?
- Do names of worktypes matter?
- In schema.org/google scholar?
- In the interface?
- What about resource types?
- Do names of worktypes matter?
Group Discussion (~30)
Share back how you designed your repository
Common Customizations to Application Flow
There are several major customizations to flow that I have seen at various institutions. We could approach it from there. For example…
- self deposit - start from uploading a work of any type; often using only a single work type
- file oriented - start by selecting the type of file being uploaded which drives work type options, workflow, collections the work can go into
- workflow oriented - start by selecting a workflow
- collection oriented - start by selecting a collection (e.g. ETD, exhibit, etc.) and what happens next depends on what you selected
The first one is the only one supported out of the box without customization.