Page History

...

Overview of DSpace Futures

Valorie Hollister

DSpace Future discussions were inspired by some momentum in the Fedora community.

• A group of Fedora users determined that they were really at a crossroads and needed to make some significant improvements in Fedora -- far more complex and involved than the normal development cycle with volunteer committers could accommodate.
• They formed a stakeholder group and established the Fedora Futures project. 
• DuraSpace held a number of calls with the community to explore what the current perceptions the DSpace community had about DSpace and whether or not there could be a similar project/s for DSpace.
• Out of those discussion we identified 3 projects that to address some ideas / needs that came up the most frequently. The first 2 project ideas have already had calls: 
  
  • 1) developing a REST API for DSpace
  • 2) creating DSpace and Hydra integration of some type  
• The third issue that came up on the initial DSpace Future calls was on the need for metadata enhancements/improvements
• This project is a bit different  -- in that the DCAT group has been working on gathering community feedback and putting together a detailed proposal for the feedback and involvement by the community. 
• Because DCAT proposal really lays the groundwork for other metadata improvements we decided to fold the metadata update project into 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 space terms into 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
• 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 of 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 - back porting 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: 

...

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

...

M

...

• DCTERMS
• Maureen: People would need help with local schema - migrate them 

S

...

• Sarah: Bring us to compliance - have local terms become compliant, give people who want to start to experiment

• Melissa? (Univ of

...

• Missouri: We've added a lot of qualifiers for more granularity - 

...

• are we locking down the qualifier and element

...

• ? I imagine there is not a DSpace instance out there that hasn't added qualifier

...

• .
• Sarah: Elements

S

...

• are made up and added - non-compliant

...

• , added qualifiers is still an open questions - 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

T

...

M

• 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

...

• Mark: Maybe the question is do you want 1 revolutions or

...

• 2 - qualifier and element lock down all at once or in stages

Next Steps:

• Val to

...

• post notes

...

• to wiki and

...

• to mailing lists, including a call for more participation – developers and non-

...

• developers to work on implementing phase one and refining plans for subsequent phases.

Begin forwarded message:

...