Page History

...

Valorie Hollister - DuraSpace

Sarah Potvin - Texas A&M

Discussion Notes

Intro - Valorie Hollister

...

• 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
    
    • UI is currently difficult to customize
  • 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 needs to have a "repository abstraction layer" - e.g. REST module (GSoC project) - give the ability to use any UIs (i.e. Drupal, Ruby on Rails based, etc) or more easily "hook up" other things to Dspace

Discussion/feedback from DCAT/Committers - ALL

...

• 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 financial 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

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 
  
  • Jonathan points out that on the Fedora side, most of the new Fedora project development is actually being done by existing committers (their institutions were willing to commit extra time to do this extra work on Fedora)
• 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

Second Meeting - November 28, 2012

...

• What Sponsors LIKE about DSpace:
  
  • meets needs for an institutional repository
  • quick to get running & 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 in DSpace:
  
  • digital preservation - some hooks in DSpace for digital preservation, but functionality to serve as a preservation tool has a ways to go
  • DSpace Admin UI tools is lacking
  • DSpace UI (XMLUI especially) is currently difficult to customize
  • multimedia needs - multimedia streaming / downloading video/images/audio files
  • open/closed content flexibility
    
    • a few institutions mentioned a need for more flexibility in dealing with open / closed (embargo) content in order to deal with copyright issues
• General institutional CHALLENGES (not necessarily DSpace specific...but related)
  
  • digital asset management 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
    • Would like ways to "hook" this into DSpace
  • backend improvements (unified)
    
    • a few institutions mentioned the need for a unified backend between Fedora & DSpace
    • this was especially important to institutions using both DSpace and Fedora (or Hydra/Islandora/another Fedora frontend)
• 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 needs to have a "repository abstraction layer" - e.g. REST module (GSoC project) - give the ability to use any UIs (i.e. Drupal, Ruby on Rails based, etc) or more easily "hook up" other things to Dspace
• DCAT & COMMITTER FEEDBACK (from first meeting on Nov 20)
  • Brought up RDF / Linked Data / Semantic web.  Some interest expressed, but not a top priority yet
  • Preservation tools -- hang more stuff off the DSpace "hooks" ( DROID / JHOVE / PRONOM / Migration jobs)
  • Concerns about "asking DSpace to do everything" - it cannot
    
    • Where do we start to draw the lines around what is "out-of-the-box" & what is third-party plugins. How do we become more modular.
    • Better APIs? (e.g. REST API)
  • Discussions about Statistics -- all feel it's such a basic need.  Interest in enhancing Google Analytics connections & Stats in general.
  • Discussions on Scalability. The more we ask DSpace to do, the harder it becomes to make it "scalable".
    
    • Brainstorms of splitting up Admin UI versus View/Browse UI (the latter can be made more scalable by caching, etc)
  • REST API / Repository "Abstraction" Layer
    • Is there a way to add "Hydra" on DSpace via the REST API (Hydra communicates with Fedora via REST as Well).
    • Would allow you to use Hydra more as a view interface...tailored to specific content types even.

...

• Ivan
  
  • +1 for author metadata / authority / author profiles
    
    • would like to do author profiles, but DSpace doesn't support author metadata well. There's no place to store this metadata in DSpace right now (for recent developments, see the dspace-cris work by CILEA)
    • This seems to be related to the Metadata For All brainstorms/initiative (which suggest to support metadata to all objects in DSpace)
  • need other types of metadata  - need to store metadata for Journals, Communities and Collections.  Currently you cannot translate Community/Collection names cause of lack of metadata support on them.
  • Also interested in Statistics – but that's a separate topic
• Mark Diggory
  
  • Seconds the idea of "Metadata for All"
  • We need to rework DSpace data model - allowing everything to have metadata - communities, collections and to allow for better translations, author profiles, local/external authority files
• Mark Wood
  
  • Revamping the "internals" of DSpace is just coming slowly. It's a lot of work.

• Ivan &  Mark Diggory

  • Need ways to support structured Metadata in general.  Currently DSpace only supports 'flat' metadata. No MODS/METS, etc.
  • Mark points out some benefits from Hydra in terms of metadata how it handles/manages/maintains METS.
  • We may want to look at DSpace model & perhaps see if we can model things that Hydra has done inside DSpace
  • But, don't throw the "baby out with the bath" – may not need to ditch all of the DSpace data model
• Leonie
  
  • Likes the idea of setting some "boundaries" around DSpace.  We shouldn't ask it to do everything. Just do the things that DSpace does well. Let it have plugins, but not everything needs to be in "core DSpace"
  • Modeling of "loose" articles in DSpace is awkward.  DSpace doesn't allow you to store journal article metadata easily
• General discussion about the need to do more collaborative sharing. 
  
  • Schools do same work independently of one another.  We should find a way to "institutionalize" a process for collaborating.  Once a collaboration is established, developers shouldn't take it offline.  They should continue to discuss on the developer list.
  • Ivan:  We should identify shared requirements/ideas on the wiki.  This step is missing
    
    • Mark Wood - agreed. Wiki is a good area for that.  GitHub also good for coding collaboration & discussions
  • Someone else said we should publicize some successful models for collaborations that have taken place.
  • Start with one or two common cases -- to "demonstrate" this as a work in progress
    
    • We've heard these common issues today.
• Leonie
  
  • Newbies and repository managers have complained to her that they don't feel comfortable bringing things up in discussion with developers.  They sometimes feel dismissed, don't feel their remarks are welcome.
    
    • Some newer folks on lists have expressed concerns about possible "negativity" on mailing lists.  Mentions that one person felt their question/brainstorm was "shot down" on list – immediate response was highly technical and seemed somewhat negative in nature. Individual said they wouldn't want to post to list again.
    • Mark Wood mentions that a "technical response" is not necessarily a negative one... sometimes it's actually meant to be a sign of respect.. but maybe it didn't come across that way
  • Perhaps we need a way for newbies & repository managers to more easily provide feedback/brainstorms.  Is DCAT the correct route?
• Mark Diggory
  
  • Sometimes questions go unanswered on the lists too.  We need to find ways to ensure this doesn't happen
  • We used to have much stronger "regional" DSpace Groups...but those have mostly "faded away".  Would there be any use to trying to bring these back?
• Someone else from Auckland (works with Leonie, but missed the name)
  
  • We need more statistical reporting.  Things like detailed totals (e.g., counts of open access items in the repository).
    
    • Tim replied that we should pull together lists of reports that people would like to see.
  • Would be nice to have graphs automatically generated & ability to generate reports from DSpace
  • Mentions they are mostly using Google Analytics
    
    • Ivan mentions that João Melo (of Lyncode) is also working on enhancements to Google Solr-based Content Analytics + DSpace.  They may want to get in touch with him & give him some examples of reports they'd like to see
  • Maybe we should ask DCAT to help us generate a list of statistical reports/charts that would be useful?   The Developers need a list to work from...otherwise we may not know what is most important.
• Mark Wood
  
  • It would be nice if DSpace itself could "plug in" to a larger structure so we could use it as a component (e.g., let other services provide statistics for DSpace).  It need not do all the statistical stuff internally.
• Tim et al.:  Some discussion of the desirability of having a "repository abstraction layer".  This could also be a way to "hook in" external statistics stuff
  
  • Ivan mentions that one could even think of the OAI 2.0 Server (rewritten OAI-PMH server now in DSpace 3.0) as a form of "repository abstraction layer".  You can actually query it rather easily (as it's based on Solr).  May be ways to use it more.
    

...