What does a Modern Repository look like? (Forget all about DSpace/Fedora/EPrints/etc. and just describe how a "repository" should fit into the modern web. What do users expect out of a "repository"? What features should a Modern Repository have? What user needs/wants should it meet?)
- not just research anymore: photos, music, data sets, video, etc
- More different kinds of content and metadata schemas
- research management systems
- CRIS moves the repository to the back-end. As CRIS will be the front end
- In edinburgh, PURE is being used with the LNI to ingest
- Needs to support "whole research workflow", Grants, etc.
- simple (visual?) import – think dropbox?
- Excel, Drag & Drop, minimal work to get things in
- DepositMO
- SWORD / SWORD2
- ScottP: submission should be much much easier.
- Bram: ScribD also had very easy upload, but poor in metadata. Nice feature in embedding lists & collections in other applications
- automated metadata capture
- content easy to use / reuse
- CRUD (needs to be able to easily Create, Read, Update, Delete – especially via web services, e.g. SWORD2, etc.)
- Support for branding / theming
- Support for Customizations (metadata and metadata structure)
- Various storage system integrations
- Flexible content workflows
- Support versioning / relationships
- flexible authorisation
- give more control to user communities (do their own branding, etc)
- Support complex objects (representation of), both human- and machine-readable
- scientific data sets
- reporting (generate useful reports
- Support content reuse ("open" data)
- e.g. embed info in dept website
- search (easy)
- faceting / filtering (e.g. Solr)
- statistics: regular reports to item authors (like Digital Commons), plus usage/admin reporting
- bot filtering (automatic?)
- getting stuff out
- shareable metadata
- different metadata "views"
- shared version vs local use metadata
- new name (not "institutional repository"): maybe just "repository" or "storage"?
- support for preservation activities
- identifiers / persistance (flexible, granular, parts of items, people, collections)
- the perils of handles...
- DOIs vs Handles
- Truly external IDs
- support access / privacy - making things "dark", either temporarily (embargo) or permanently
- "repository / DAM system that can display stuff vs. CMS that can do DAM"
- flexible metadata schema
- dissemination
- make data usable / able to be "mashed up"
Some Additional Details / Specifics:
- Richard Jones: DepositMO project
- dropbox like interface
- integrated in Microsoft Office.
- Mark Diggory
- Changing Branding
- Presentation of Metadata
- How well the metadata can be structured in a repository
- Integration with other storage systems
- Customization on the workflows
- Richard R?
- Versioning
- Relationing technology: linking items and content to each other
- Sarah Shreeves
- Giving more control to the user communities: delegated administration on steroids
- Good representation on complex objects
- Adam Field (eprints services)
- Reporting (getting data out of the repository in a non-publications form)
- Integration with other websites
- Search data well
- Bram
- Statistics for Repository authors to get more traction
- annual reporting gets more demanding
- Richard
- Brad mclean
- Getting things in & managing
- Getting things OUT again
- boundaries of a repository are institutional, but ideally you might want to break down those boundaries and make them more disciplinary
- Richard rodgers question: did OAI-PMH failed in this regard?
- Mark Diggory: one problem related to that: missing official taxonomies?
- Elin: problem for disciplines that have no good aggregators yet. It would be a huge motivator for them.
- Richard Jones: Creating ad-hoc sets that can be easily shared
- Bram: the issue is not technical. Which organization will put up the effort & the money to make these big portals possible. (example economists online)
- Stuart Lewis: could not be "one" repository, but different ones. It's a service, not one monolithic thing
- Elin: focus is not about offering storage, but offering assistance with their content and metadata
- Robin: "for completeness" we can include Preservation. Justification for having the repository is that it does the preservation (versus CRIS).
- Stuart: the features for preservation are present only need to be used
- Tim: DSpace enables preservation but doesn't do it in itself. Preservation requires people, policies. No technology/system does preservation – it can only enable one to perform preservation activities.
- Jones: Person identifiers
- Diggory: all of your accounts, personal accounts in DSpace?
- Scott: I hate handles
- Rodgers: handle vs internal identifiers. Google Scholars … handle are the work of the devil (no content in the URL's). Exposing metadata in the URI is the way to go.
- Scott: main point for handle "moving content" to other insititutions is not possible in DSpace.
- Sarah: Handle "forces" a good practice in standardized URI citation.
- Stuart: Academics start to understand DOI. Crossref. Selling handles as DOI's.
- Mdiggory: Nescent work with DOI registration. True sense of the use of identifier. Identifiers lives outside of the repository.
- Jones: the modern repository needs to provide an identifier. But not sure whether it should be persistent, or be linked to an external service. Granular identifiers required (datasets, bitstreams, …)
- Mdiggory: privacy & private items, access controls.
- Jones: do we really want to add a lot of CMS features?
- Hardy: more user interface support for UI's. map viewers, image viewers, …
- Mwood: why doesn't do the browser do it?
- Robin & Richard: how do the fedora folks look at this? Fedora should be pretty good at the "invisible repository" bit.
Whiteboard photo (click for full resolution):
Additional Close-up Pictures of sections of Whiteboard:
(click for full resolution):
Top-Left closeup:
 |
Top-Right closeup:
 |
Bottom-Left closeup:
 |
Bottom-Right closeup:
 |
Closeup of additional Scratch Paper:
 |
|