EDITING IN PROCESS

The following are notes from the initial community meeting to discuss the proposal to update the QDC registry and add DCTERMS registry from March 20,2013.

...

Overview of Metadata Improvement Proposal

Detailed proposal: Updating the Qualified Dublin Core registry in DSpace to the latest standards of the DCMI

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

• project arose from community survey
• DC default schema currently
• Local instances modify dc default schema, having a more standard schema would be better
• Laid out possible phases of update - ultimate goals to move to DCTERMS, done in phases
• Start with update to current QDC , DC ('dc' would stay), add DCTERMS, would also be a local schema and an administrative schema open to modifications, but 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, interfaces, 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" a schema for admin metadata, maybe 'dspace'
  
• ?: 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 (with versions allowing multiple schemas), 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 ability to add schema  -- but 1.6 5 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 DCTERMS 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 parallel 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
• 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 would 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

...