Page History

...

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

...