Page History

...

Peter Dietz, The Ohio State University Libraries

Felicity Dykas, University of Missouri

Notes

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

...