Page History

...

• Questions around DSpace w/ Fedora Inside updates.
  • Essentially DuraSpace still highly interested in this initiative. However, no active development going on. There have been ongoing discussions/brainstorms.
• DuraCloud & ReplicationTaskSuite questions
  • Talking through how Replication Suite works with DuraCloud --> DSpace generates AIPs (in either METS or BagIt packages), those get replicated to DuraCloud. In your DuraCloud acct you could choose which underlying storage providers (e.g. Amazon) to use. Can use one, or even replicate across multiple providers (or move between providers at a later time).
  • Main use case is backup & restore (and helping DSpace admins to automate it as much as we can)
    • Currently an automated backup can happen via a ReplicateConsumer which can queue AIPs for upload whenever something changes in the system. Still a work in progress though. Working on stabilizing it.
  • Brainstorming some future use cases – one that came up is storing high-res archival quality images/videos in Cloud (DuraCloud), and using DSpace for access copy.
    • Replication Task Suite can support this as it lets you decide which Item Bundles you want included in AIPs. So, you could only include the "high-res" Bundle in AIPs, and exclude any Bundle which had access copies.
• Metadata For All Objects (briefly touched on)
  • Is the "biggest bang for buck" just Bitstream metadata (esp. preservation/technical metadata)?
  • No, also need for enhanced Collection & Community metadata. Some use cases include:
    • Multi-lingual Communities & Collections
    • Subject Headings on Communities and Collections (as a way to more easily search them or organize them)
  • Bitstream metadata also very important. Especially looking towards JHOVE or DROID. Essentially, storing preservation/technical metadata about files is important.
  • Richard's Modernized DSpace work allows for Bitstream metadata (at least skeleton code is there).
  • Question: How should Bitstream metadata be exposed via Search/Browse?
    • Likely Configurable? But configuration can be difficult, if Bitstream metadata is very heterogenous (different schemas, etc.)
• Discovery / Solr
  • Discovery is working towards making facets pluggable (develop new facets), also working towards making indexing pluggable.
    • The latter (pluggable indexing) may be useful in allowing for different types of objects/content to be indexed in different ways (This goes back to question about how to index/expose Bitstream metadata)
  • Big Question: Should we think about making Discovery the only Search/Browse option? It would allow us to potentially simplify indexing issues as we get into Metadata on All Objects – since we can work towards one solution (Discovery/Solr) rather than multiple at once.
    • What would this mean? Essentially we'd replace the "/search/" directory (old Lucene Indexes) and the DB Browse tables with Solr. All searching/browsing would use Discovery, which currently only works with Solr (but should be pluggable to use other underlying technologies – more below)
    • Some Concerns / Questions posed:
      • Does it need to be Solr? Can't we also achieve this abstraction using just Lucene (which now has browse-based libraries), or even a Solr alternative?
      • Also concerns that Discovery in DSpace 1.7 was a bit buggy (possibly even a small "step back"). However, DSpace 1.8 looks to be better. Still, Discovery may need more testing to ensure it's stable & ready.
      • What about JSPUI? Discovery doesn't work yet on JSPUI. Two options: either port it to work with JSPUI (there was some interest in past), or else we'd have to think about deprecating JSPUI altogether.
    • Discovery in DSpace 1.8 offers more abstraction. It's now more "pluggable" and you could hypothetically use something besides Solr. Though Discovery obviously assumes that whatever it is using has similar features to Solr (faceting, etc)
      • Might be interesting if someone were to try running Elastic Search (http://engineering.socialcast.com/2011/05/realtime-search-solr-vs-elasticsearch/) under Discovery.
    • Also worth noting that Solr Statistics can be separated from Discovery. They can uses entirely separate Solr instances as needed (for better scalability of each).
    • Seems to be some interest in consolidating browse/search around Discovery. But, also several outstanding concerns (see above) that need to be answered.
    • One reason to like Discovery (from Stuart Lewis): http://blog.stuartlewis.com/2011/08/26/the-collection-is-dead-long-live-the-collection/
    • @Mire has some extra documentation about DSpace 1.8 Discovery changes it will be sharing. It's imperative that we work to ensure Discovery directions are brought towards central Committer control. That way we can get the proper 'buy-in' to make sure we can all support it, etc.
• SkylightUI - https://github.com/skylightui/skylight
  • Different sort of PHP-based UI for read-only searching/browsing DSpace (built out of Auckland). Uses DSpace's Solr indexes (built by Discovery)
  • Uses Queries Solr directly, rather than DSpace REST API, as Solr provides native replication support.
  • Essentially just goes against Solr's own REST interfaces. Uses Solr as a "read" API.

...