Versions Compared

Old Version 94

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 95

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

  • SKOS Authority Controls
    • SOLR Based authority control plug for DSpace. Term completion against stuff you put in your SOLR.
    • Always lacking: authority control is always a list, but controlled vocabularies are graphs/networks. Usecase Nescent: SKOS Hive (built on sesame) authority source, now exposing this through SOLR in DSpace submission forms.
    • Feedback on enhancing authority control in DSpace:
  • WebMVC (Freemarker UI development) - Talk on this Saturday
    • Instead of newer features, project is mainly focussed on completing the existing UI functionality. (a modern JSP UI).
    • Feedback on WebMVC
  • Submission Enhancements in DSpace
    • In-browser interface to edit the submission interfaces
    • Feedback on submission enhancements in DSpace:
      • (Elin noted we need to be careful about our usage of the term "Workflow".. developers sometimes have a different interpretation to community)
    • Reviewer workflow - Talk on this Friday
    • Framework for more flexible workflows (different edit steps, etc)
    • Feedback on reviewer workflow:
      • Elin: need for a common terminology on Workflow vs Submission. Is Submission part of the workflow according to the developers?
  • New UI built over RESTful services
    • Yes, it's kind of a new UI. But more oriented over building widgets, over the REST API.
    • Aimed at better testing the REST API
    • Returning student (Bojan) now serving as mentor, which is a 'GSoC first' for DSpace
    • Licensing (strict GPL requirements) has become a big factor in decisions re: toolkits/frameworks/etc to use

DSpace with Fedora-Inside Brief Updates:

  • Long term project.
  • 1st step already passed: being able to move DSpace objects around. AIP exporter for the whole object (metadata, content, access rights, ...)
  • Goal: using these AIP packages to feed a fedora with.
  • Next step: how will this exported data be well represented in Fedora?
  • After that: how to put business logic of DSpace on top of Fedora. Problem: not enough technical staff in Duraspace, so it will take a long while. In addition, DuraSpace doesn't want to do this work alone, as individual institutions better know the needs/requirements. DuraSpace is looking for other stakeholders to jump in, participate and speed things up.

...

Note

Although a decision was made to retire the name "2.0", this has not yet been announced in a more public fashion (on mailing lists, etc). The reason is that DSpace 1.8.0 will still be called 1.8.0. After the 1.8.0 release, we will make a decision on what the following 2012 release will be named (likely either DSpace 3.0 or 9.0). At that point in time, we will announce the retirement of the name "2.0" (though many features of the DSpace 2.0 Prototype will continue to be added to DSpace little by little), while also announcing the new version of DSpace.

So, in summary: DSpace will likely change its version numbering scheme after 1.8.0 is released in Oct 2011. At this point in time, we are undecided what that new version numbering scheme will be. However, we will likely skip over the number "2.0", as that version has too much past history and assumptions built up around it. In the end, we hope to simplify and clarify our numbering scheme. As always, DSpace will continue to release at least one new major version each year – it's just that after 1.8.0 the DSpace version numbers may look slightly different than in the past.

DCAT Update / Feedback

  • They've been taking new feature requests from JIRA, members pick issues that are of interest to their institution or that they've heard interest for, figure out prioritisation that way
  • They've been through about 5 new feature requests this way so far
  • Feedback from committers/developers is useful – coming back with further requirements, etc.
  • Some issues require participation from the broader community, DCAT will be working to enable this
  • Also working with DSpace ambassadors to try and reach repository managers that might not follow dspace-tech or be involved via usual channels
  • Has been a bit slow to start, but it has been really helpful having Robin (in capacity as 1.8 release coordinator) and Tim join in the DCAT discussions
  • Encouraging members with a particular interest in new features/issues to join in on IRC committer meetings
  • Robin: One benefit has been giving repository managers a voice and making sure developers don't just follow their own pet projects, remind them of real-world priorities
  • Tim: gives us a perspective outside of our own institution
  • Stuart: Can we get a new flag or status in JIRA so we can get DCAT review of issues we've written code for
    (or issues we don't feel are clearly defined... instead of them ending up stale because we couldn't figure out how to move on them in a committer meeting)
    • TODO: Tim will investigate ways to "flag" an issue in JIRA as "needing a DCAT Review"
  • Bram: How many of the 1000+ repository managers are involved in meetings/conferences/any kind of communication where they can express their requirements, issues, ideas? Eg. I use MS Word but I don't turn up to MS focus groups on word processor design. Would be really cool to cross-ref the list of dspace.org listed instances, and people registered on the mailing lists, to find out about those listed on dspace.org who are NOT on the mailing lists. They might need some extra attention to get involved.

...