...
- What Sponsors LIKE about DSpace:
- meets needs for an institutional repository
- allows for open access to content
- useful workflows
- lots of excitement about features coming in 3.0 and features available in 1.8
- What are some of the CHALLENGES Sponsors face
- digital preservation - some hooks in DSpace for digital preservation, but functionality to serve as a preservation tool has a ways to go
- front end / tools for Admins / UI improvements - customization needs to be easier and more flexible/modern (i.e., customize by collection) and more accessible for Admins
- multimedia needs - multimedia streaming / downloading video/images/audio files
- digital asset mgmt strategy - several institutions are in the middle of a review of their overall strategy, particularly as it relates to research data management
- data management - many institutions mentioned the need to store data and present it in different ways, also the ability to get data in and out of DSpace easily
- author identity / author profile - need to allow content to be showcased in different forms (i.e. BibApp, VIVO) - don't want to re-create metadata or content
- backend improvements - a few institutions mentioned the need for a unified backend
- open/closed content - a few institutions mentioned a need for more flexibility in dealing with open / closed content in order to deal with copyright issues
- What are Sponsors INTERESTED in:
- DSpace/Hydra - a lot of curiosity and interest in the potential of creating a DSpace Hydra head, Univ of Hull has a IR Hydra head, several institutions would like to have one solution for all content (student/faculty, digital collections, data, etc.), some concern about re-creating the DSpace workflows - critical that DSpace maintain its core functionality
- DSpace/Islandora - a few institutions interested in Islandora - which is a Drupal frontend with a Fedora backend, some believe it might be easier / more accessible to customize Drupal than Hydra and that Drupal would provide more flexibiilty for displaying digital assets
- DSpace to be an abstraction layer - REST module (GSoC project) - give the ability to use any UIs (i.e. Drupal, Java-based)
all - discussion Discussion/feedback from DCAT/ question
Discussion
...
Committers - ALL
- Bram: any comment/feedback on RDF/linked data? No, it didn't come up in the most recent discussions
...
- Amy: we would be
...
- interested, but not at top
...
- of our list
...
- -
...
- preservation, streaming would come first
-preservation
...
- Stuart: preservation important - not hanging anything off the hooks in DSpace - there is a bitstream registry, but don't really use it, no reporting mechanism, need to extend that
...
- support
- Elin: preservation important - need to be to do things like identify files at risk
...
- , have the ability to export them out
...
- to something like DuraCloud and then easily import it back
...
- – linked back to original metadata
...
- Stuart: need to ask what we see the direction of DSpace
...
- ? preservation, great interface, streaming, RDF imagining - is it possible to do everything? or should it be something modular?
...
- Jim: functionality doesn't have to be native to DSpace - like APIs - digital objects can be stored and preserve -
...
- but just clicking on a button
...
- to download might not be enough - need it to preserve and provide access to whatever people want to put in - I am selling DSpace as a place to put data at our institution
- Bram: have sponsors mentioned interest in leveraging
...
- repositories as source for out-metrics
...
- and more advance statistics?
...
- Not specifically.
- Amy:
...
- looking forward to elastic search in 3.0
...
- Tim: elastic search
...
- is just a different backend to stats (vs. SOLR), not additional reporting,
...
- aggregating stats might help store more data, but we need to work out what are the reqmts for statistics
- Sarah:
...
- interested in Google Analytics - stats is a pain point for us
- Maureen: stats are important
...
- - using elastic
...
- search because of scaliablity issues, but doesn't solve all of what we need
- Alana: stats are important - our needs are different than normal IR - but helps to justify our existence
...
- Elin:
...
- stats are a basic need - Cambridge hasn't been getting statistics we need - looking for Google Analytics plugin to help
- Bram: Google Analytics vs. existing stats in DSpace - tough tracking downloads - could be opportunities to registered w/Google Analytics, need to think about how stats could be used in the future
- Maureen:
...
- scalability is a challenge - we moved to
...
- elastic search because of scalability - being
...
- able to handle the scale and have functions operate properly - basic performance issues, java error codes - not sure what the problem is - whether it is scale or something else -
...
- repository has 50,000 items and 100,000 files
- Stuart:
...
- do we need to look at general architecture changes when it comes to
...
- scalability - do we split end user functionality / admin functionality - a lot of checks in DSpace - is there a scalability advantage in spliting them?
- Tim: repository abstraction layer - does that allow us to do what Stuart is talking about - create a read-only interface and a
...
- separate admin interface to manage
...
- content - could you use REST to plug into Fedora?
...
- Stuart:
...
- makes more sense to build Hydra on top of DSpace - or Islandora on top of DSpace - keep workflows - might make more sense to duplicate
- Tim: taylor interfaces towards diff types of content - sounds plausable, not sure if it is possible - step 1 would be to make sure DSpace has a reposibory abstraction layer
- Tim: have a REST API that was built as a GSofC project - had some
...
- scalability problems and access issue (everything open) - several project forks in Github - 2 diff forks 1) HDTEK, 2) WIJITI - have resrouce gap to analyze/review code - if one is better than the other, if they can be merged together
- Jonathan: managed projects idea
...
- - in the Fedora community institutions interested in getting the work done have started a project - agree on set of features that are critical to improving Fedora now
...
- , project participants have committed in-kind donations of dev time (mostly more time from current Fedora committers) as well as finanical support of tech lead and project manager
...
- Jonathan: for DSpace
...
- we hear a lot of diff interests and
...
- ideas -
...
- if more ambitious ideas are going to take place, it will have to similar to Fedora
...
- , would like to hear from anyone who has specific projects that you would like to help with
DCAT ROLE
...
Next Steps - Valorie, Jonathan, Tim
- Have one more DCAT/Committer call next Wednesday
- will summarize / make transparent what the feedback has been from all mtgs / discussions - likely posted onto the wiki and distributed via the mailing lists
- not sure what projects will come out of discussion - need to determine who has common
...
- interests
...
- want to include everyone who's interested in
...
- those projects
- DSpace community has to get the momentum - need more developer time / resources to work on projects - either new developers or more time from existing developers
- DCAT's role will be similar to other development in DSpace - provide feedback on features, make recommendations based on different institutional perspectives
- Committers will help project answer questions and review code submissions
-DCAT help promote projects - give feedback
-Committers - help review code
-community has to run with it - we can help - Fedora Futures is a good example - grass roots movement, invited us to take part - but it came from them - how could something similar happen in DSpace
...