Page History
...
- Do we need two platforms? DSpace & Fedora
- Need to see if the 3-5 yr "visions" overlap for the platforms. Think of as a venn diagram - may be a lot of overlap or little
- Would be important to the University Librarians - need a message as to why give to one or both. Show that we've analyzed whether merging platforms is worthwhile
- Types of DSpace institutions
- Institutions who are essentially happy with DSpace as out-of-the-box IR
- Institutions who are stretching the boundaries of DSpace
- Faculty wanting something easier to use, "flashier". Even building their own tools, using other (non-preservation) system
- "In between" - like the simplicity but want "flashier" interface, similar
- Is there a common vision for DSpace? (even amongst our small group)
- In many ways it has morphed from it's initial use case that is was built for
- Should it be a generic digital repository, or concentrate on solving just IR / preservation repository?
- Institutional Visions / Use Cases
- Institution #1 - Lots of integration points & access - less about preservation
- DSpace is free, relatively robust. Large User community.
- End user deposit. published & unpublished content
- Managing diverse research output (ORCIDs). Data with access controls. Digital Collection & Mgmt)
- Research info mgmt systems. Needs good integration points
- Integrates into a different digital preservation.
- Streaming server, stats module were added as they went
- "Killer App" = E-Theses. Harder stuff is images/video.
- Institution #2 - Started small and simple, constantly expanding
- Initial decision was it is open source. Philosophy to support OS
- Capturing university output
- Getting to streaming servers
- "In between group" - like ease of use. Small library - students could be used to do input
- Migration of some content from ContentDM to DSpace. Having requests to extend DSpace to add some ContentDM features
- Feeding publications (university publishing) direct to DSpace
- Getting data in and out easily
- Went with Islandora for a Digital Library solution (better "Digital library" product than DSpace).
- Question has come up whether to use Islandora instead of DSpace for some content
- Possibility: Using DSpace as a true "preservation repository" and feeding content to Islandora (or similar)
- Positives outweigh the negatives at this point. But, how many systems can they really support amongst digital library / IR services?
- "DSpace with a lot of 'hooks' on it" - could solve a lot of use cases with good integration points. But, shifts focus of spending staff time integrating and supporting a larger suite of software.
- Institution #3
- At time of adoption (early on), unique & filled a necessary role. Capturing the scholarship in a repository (initial needs came from library community)
- Main concerns are performance issues / scalability
- Handling preservation mgmt
- Continued modularization of DSpace - lots of things people want, but do we keep adding into DSpace.
- DSpace not a swiss army knife.
- Lack of flexibility for non-text formats
- Handle issues - cannot move content around easily as you cannot "split" a Handle prefix
- Institution #4
- Important that it is OS and successful with textual formats. Good submission workflows.
- Built up a lot of local expertise with DSpace
- DSpace as sole Digital content mgmt system
- Lots of user demand for images & data. DSpace not designed for these materials
- Need for stronger preservation support.
- More complex metadata
- Moving in a more modular direction. Want DSpace to fit well into that ecosystem (modular instead of "stand alone")
- Not the staffing to support Fedora. DSpace is "perfect fit" in that it's turnkey, etc.
- Institution #5
- DSpace provides Persistent long term access. Easily findable items
- Want a system that can meet multiple types of needs. Not enough staff to support many systems
- DSpace is part of preservation strategy (and DuraCloud and other tools)
- Need for stronger preservation support
- Need to better support special collection
- Journal article metadata becoming more critical. As is data
- Want it to also "work well with" streaming server solutions (for video / audio). Better integration
- Institution #6
- At the time, it was the "out-of-the-box" product
- Place to put documents for easy access.
- Using both for archival materials and scholarly content
- Future to make it look "partitioned" to search types of content separately
- Integration with things like Symplectic Elements and/or VIVO. Pull in metadata from external sources (easier deposit)
- Data becoming more critical. Both open access data, and data only for local community
- Managing research data (long tail data...small data)
- Hard to get stuff out of DSpace once it is in there (e.g. move it elsewhere). Handle issues (cannot split up handle prefix)
- Willing to run different systems for different purposes. But, limited staff – so needs to be easier integrations. Simplicity important
- Institution #7
- Role: mature IR platform, but has not evolved to solve all the various other use cases beyond narrow IR institutions
- Imagine DSpace as an IR "backbone". Enforces various use cases for IR needs. But interoperate with other tools/services that can solve other use cases
- Interoperability with Tools: e.g. DSpace more friendly with existing tools that solve preservation problems / dissemination, etc.
- Interoperability with Services: Large user community, which could be leveraged to build an 'ecosystem' of services which are "DSpace-aware".
- Framework for modules/plugins , which would allow institutions/service providers to integrate other services into DSpace. Could be supported by DuraSpace
- Don't want to build more & more functionality on top of a monolith. Want to create an "adapter" to plugin to other services & tools.
- Some examples: Discovery & Access
- E.g. specialized interfaces for searching across ETDs. Perhaps ways to link that up to printing ETDs.
- E.g. distributed digital preservation
- Why use DSpace instead of something else
- sunk costs - costs to switch
- not a lot of digital content solutions that meet the base IR needs
- Institution #8
- Twin goals of DSpace: preservation & access to research & scholarship
- content has to be related to research / scholarship. Other types of content go in other systems
- Worked well for that purpose. Works well with textual docs.
- Now getting some images / research data sets. Small sized to medium sized data sets, DSpace works well
- Limitations in terms of preservation side of things
- investing in Fedora as a preservation platform (for all content, not just IR)
- DSpace will be more of an ingest/access system. Preservation will be in a separate platform "underneath"
- Need to move content easily in/out of DSpace because of that
- Increasing value. Use ability to delegate control of Collections & Communities to departments to do their own training/submissions. Easy for people to pick up and use in that way
- Have a large amount of "sunk costs". Would like to see platform/community move
- DSpace should continue to provide base IR functionality. But, expand to handle more complex environment (e.g. relationships between sets of items).
- DSpace should either improve with Preservation or have easier hooks to other preservation tools/services
- Easier hooks into research profiler system or similar
- Twin goals of DSpace: preservation & access to research & scholarship
- Institution #9
- DSpace is about Preservation, visibility & access to your work
- Dspace great at end user deposit, creation of collections.
- Do virtually zero vetting of what goes into DSpace. Trust faculty to make this decision
- "Directors cut" - multiple things under one handle
- Good that you can put anything in it. Can be a preservation problem
- Preservation tools could be improved.
- Like open source nature.
- Want to look at handling small or large data sets in DSpace
- hard to get stuff "out" (especially large data sets)
- Concerns about the monolithic nature of code. Need: "set of legos"
- Institution #1 - Lots of integration points & access - less about preservation
- Pain Points / Frustrations
- Poor end user experience
- Customizations are "hard". Plugging things in. Code modifications (monolithic)
- Hard to maintain once you make customizations. Upgrades become more painful.
- Current Content Model - especially difficulty with relationships
- metadata per bitstream (e.g. preservation or admin metadata)
- different types of files all related, but requiring their own unique metadata
- hierarchical metadata
- relationships between items
- Needs a more flexible content model in general (hierarchical content model)
- for preservation use cases, you might want to organize in on way. for access, perhaps another way
- Communities, Collections & Items hierarchy do not work for all use cases
- inflexibility of this model causes you to have to work around it or "hack it"
- metadata per bitstream (e.g. preservation or admin metadata)
- No native support for complex metadata
- Research data metadata is hard
- Lack of training possibilities
- Lack of user documentation for DSpace
- Cost of ownership. Making installation/configuration/upgrades easier
- DSpace primary UI technology based on aging technology (Cocoon)
- Ease of use of getting data in/out of DSpace (metadata, actual content, etc.)
- Getting data out in a form that is "useful" to researchers (for data mining, etc)
- Also statistics lost if you move data out and back in
- Scaling concerns.
- Concurrency issues (tuning for large scale concurrent access)
- Scaling issues related to Collection size
- Getting content in/out
- Delivery of large files out of DSpace
- Also getting large files into DSpace
- Improved support for Bulk Uploads into DSpace (not to have to send to your programmer)
- Governance & getting things (fixes / features) into the codebase. Not enough developer resources.
- Model to share common tools into a "commons" that are "DSpace aware". Lack of a framework to share these tools & manage.
- Repository Use Cases
- Large research data sets / large files / big images/videos
- Need for streaming video / audio service
- Integrated publishing system
- publish journal articles
- Current Research Information System (CRIS) (BePress does that...why doesn't DSpace)
- Faculty Research Pages
- e.g. Hong Kong's work with DSpace-CRIS
- Preservation Management
- Newspapers, Serials, Complex Objects in general (or interoperability with an external system to handle)
- Interoperate in general with external tools & services
- Interoperability at any level of the DSpace hierarchy (Items/Collections/Communities) to other services
- Archival vs. Access Copies - distinguishing different file types (for different use cases)
- Storing master images (archival copies) - tag it in a particular way for preservation services
- But, display a lower resolution copy (access copy)
- Almost better relationships between files (and allowing metadata on individual files)
- Building different access "views" of objects (based on the type of content or audience or similar)
- Possibly enabling different functionality per type of content (e.g. image viewers, document page-turners, ETD search/view, geospatial data)
- Not necessarily a different interface, but a different "visualization" of content.
- Image Server / Page Turner / Geospatial / Media Player
- More ease of branding. Not having everything be "DSpace-wide"
- More customization abilities / theming at Community/Collection levels.
- Making this process easier. Provide a set of templates / base themes. Manage this from the UI or similar
- Version control
- In the control of the end user. So end users can choose when to version/update their content
- Mediated & Author self-deposit
- Mediated - approval workflows, batch loading
- Metadata Editing
- Batch tool that is Admin UI-based
- Self-service configuration (manage configuration from the Admin UI)
- Ingest forms
- Controlled vocabularies, etc.
- More admin tools made available to UI
- More Metadata Schemas
- PREMIS
- Geospatial
- Tools that automate extraction of technical metadata (e.g. duration of videos, other admin/preservation metadata)
- Granular Access Controls
- Limiting access to new Item deposits as needed
- Better communicate what is open access and what is restricted access
- Identity Management
- Author IDs
- Object IDs - Not just Handles (also DOIs or other identifiers)
- Authoritative Handling of Identification
- Statistical Reporting
- Usage statistics (filtering out spiders/bots by user-agents)
- Analysis of repository content
- Search Engine Optimization
- support different use cases
- need to constantly keep on top of it
Overview
Content Tools