...
How to use admin sets as policy objects
Types of Repositories
Institutional Repository
- purpose: is to collect research output of the university
- depositors: either deposited by content creator or by a designated group
- typical content:
- data
- article
- white papers
- anything
Digital or Managed Collections Repository -
- purpose: is to collect curated content
- depositors: smaller number of depositors, larger number of content
- typical content:
- media
- digitized books
- manuscripts
- center
Multipurpose Institutional Repository
- purpose: support both types
- depositors: mix of self deposit and staff deposit
- typical content: mix
Designing for Use Cases (~1 hour)
...
- How items come into a system? May have multiple workflows to support many different purposes.
- 1 time users
Digital Collection
- Fewer people (depositing works into) working with the system.
- More homogenous workflow.
...
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?
...