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?
- 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)
- 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