Monica Rivero's List: DCAT

• establishing a true "API" for DSpace legacy objects
• enable metadata for all dspace objects
• Refactor Metadata Schema
• enable multiple metadata schemas per default (dcterms, an
   administrative one and a couple of standard namespaces like those used
   for prism
• manage metadata field related configurations like hide option,
   display, browse, search etc. in the db rather than in dspace.cfg
• • Metadata Sections may have ResourcePolicies attached to control access to them (protected provenance metadata, administrative metadata, etc)
   
  • Metadata Sections would be stored in Bitstreams
• Rendering views on DSpace resources will become more file access centric rather than database query centric (will have its own benefits and caveats)

  • Why is this better?
• Common metadata content model
• all Hydra objects will subscribe to a common metadata content model which provides for the types of metadata that all objects are likely to need.
• Datastreams
• * technicalMetadata (XML) (optional), may contain
   ** PREMIS premisObject
   ** type specific (e.g., MIX for images)
   ** etc
   * provenanceMetadata (XML) (optional)
   ** eg PREMIS premisEvents
   * sourceMetadata (XML) (optional)
   ** eg METS sourceMD snippet? (only a wrapper to object-specific MD)
• would add dmdSec for metadata attached to Bitstreams and Bundles would be associated with the those files
• Authority Controls again are a UI feature for managing metadata values in form fields etc
• turned into a "one metadata proposal to rule them all" page.
• Don't get me wrong, I think each of these ideas has merit & is worth close consideration. I just think they don't all need to be implemented simultaneously nor are they all interdependent.
• sound like a rather large change (affecting a lot of code, especially editing/submission code in the UIs). So, it may need its own discussion page where we can start to dig deeper into the benefits/caveats and what they may mean for DSpace.
• I agree with taking it in stages, but I'd still want to separate these various projects out more. Everything is still lumped together under "Metadata for All" when most topics technically could be only loosely related (or even parallel) projects.
• For example:
• Essentially, we shouldn't be treating these all as one big project. Rather, we should work to split them up into smaller, more manageable chunks. That way we can reasonably expect some of this to make it into 3.0, and then make further enhancements in 4.0, etc

17 more annotations...