Page tree

Versions Compared


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


Peter Dietz, The Ohio State University Libraries

Felicity Dykas, University of Missouri


Overview of DSpace Futures


  • Richard, MIT: What is the scope and vision? Agree metadata models are in need of refurbishment. What is the thinking about actions to take on current installs or new systems moving forward?
  • Maureen
    • we do want to help current instances upgrade, not just new instances
    • lots of technical issues - what is the graceful path forward? need to provide tools and update crosswalks and review everything this would affect - add ons, features, etc.
    • we are talking about helping current instances
    • we would provide tools to do an update - these are the registries and here is what you have to do to overlay - have to help people address
    • always going to have a schema named dc (not repurpose the name)
  • Bram: Want to mention a bit about the benefits/inconveniences - further we are away from standards, the more overhead for importing and exporting - goal is to lower overhead costs on import/export and to be in compliance with standards
  • Mark: Think this is basically a sound proposal, like the overall shape, something we need to do
  • Maureen: Lot of areas we need to flesh out / some areas to make decisions yet on - put comments in wiki page
  • Mark: Concerned about possibility moving DSpace-specific terms into institution-local - local should be local
  • Maureen: Yes, local should be just what local needs are, could move DSpace admin metadata into something call "Admin" for admin metadata
  • ?: Does the proposal suggest a flat DCTERMS vs. or does it imply we will need a new data model?
  • Richard: If we stick with flat we have a chance of reaching that with existing sites - expanding registry. If we change the underlying data model we can't, because older versions of DSpace didn't allow editing the schema (approx. sometime before DSpace 1.5)
  • Maureen:
    • Phase 1 and 2 is backward compatible, phase 3 may not be/not sure of implications - maybe that full implementation of DCTERMS means that there would be a break
    • Try to update old version w/tools - but tools would really be designed  for upgrade process (like SWORD upgrade)
    • Write off older versions that don't have a schema in them -- but 1.6 and above we may want to consider
    • Some of the tools may be usable with earlier versions w/schemas - backport tools
  • Mark - Phase 1 seems cheap
  • ?: Confusion when we have multiple schemas that have semantically the same fields - how do we allow for almost identical fields?
  • Maureen: Both DC and DCMI would be there - so we'd have to set a default schema
  • Tim: Phase 1 - only adding a parallel schema - cheap, starting to create migration tools, parrellel schema to look at it and think about and start to migrate before jumping to DCTERMS
  • Maureen: People would need help with local schema - migrate them 
  • Sarah: Bring us to compliance - have local terms become compliant, give people who want to start to experiment
  • Melissa? Felicity:  (Univ of Missouri): We've added a lot of qualifiers for more granularity - are we locking down at the qualifier or element level? I imagine there is not a DSpace instance out there that hasn't added qualifier.
  • Sarah: Elements are made up and added - non-compliant, added qualifiers is still an open question - should they be moved into the local schema, probably outcry if we don't allow for qualifier - but to think about moving them to local at some point during the migration
  • Tim: No new elements and then figure out how to manage custom qualifiers later
  • Maureen: could lock down on UI, could allow people to change code (Richard: customizing the code will be always an option)
  • Mark: Maybe the question is do you want 1 or 2 revolutions - qualifier and element lock down all at once or in stages