Versions Compared

Old Version 2

changes.mady.by.user Valorie Hollister

Saved on

compared with

New Version 3

changes.mady.by.user Ivan Masár

Saved on

Key

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

...

Valorie Hollister, DuraSpace

Ivan Masár, DSpace commiters

Peter Dietz, The Ohio State University Libraries

Notes

Overview of DSpace Futures

...

Maureen Walsh and Sarah Potvin (other proposal team members include: Amy Lana and Bram Luyten) 

  • project arose from came from community survey
  • DC default schema currently
  • Local instances modify dc default schema, having a more standard schema would be better
  • Laid out possible phase phases of update - ultimate goals to move to DCTERMS, done in phases
  • Start with update to current QDC, DC would stay, add DCTERMS, would also be a local schema and an administrative schema open to modifications, but that we are urging that we lockdown standard schemas

...

  • 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 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 . 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 of 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 - back porting 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? (Univ of Missouri: We've added a lot of qualifiers for more granularity - are we locking down at the qualifier and 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 questions 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 revolutions or 2 revolutions - qualifier and element lock down all at once or in stages

...