What resources are we focussing on?: Difference between revisions

From wiki.dpconline.org
Jump to navigation Jump to search
No edit summary
No edit summary
Line 28: Line 28:
       Determine IPR and sensitivity issues. Are they known or do they need to be reviewed?
       Determine IPR and sensitivity issues. Are they known or do they need to be reviewed?
       Ensure that depositor condition are clear (closure periods or embargos, reproduction rights, etc.)
       Ensure that depositor condition are clear (closure periods or embargos, reproduction rights, etc.)
       Define use cases. Define user requirements (as far as they can be anticipated).
       Define use cases. Define user requirements (as far as they can be anticipated). For example authenticity.
        
        
*What is the condition of the 'stuff'?
*What is the condition of the 'stuff'?
Line 52: Line 52:
       **reactive (provide files as-is and wait for problems to be reported)
       **reactive (provide files as-is and wait for problems to be reported)
        
        
       What degree of stabilisation of assets is required via migration/emulation etc.
       Decide what degree of stabilisation of assets is required via migration/emulation etc.
 
 
What is the authenticity requirement?

Revision as of 16:49, 31 July 2013

  • What resources do you have available?
     Money and people/time. Find out whether you can make the case for one or the other more easily.
     Know whether this is entirely new, or an extension of something you are doing already in part or in whole.
     Think about: staffing/skills, technical infrastructure (storage, processing), processes (e.g. cataloguing)
     Distinguish reccurent costs from capital investment costs.
  • Where does the stuff come from?
     Know your mandate, collecting policy, retention schedule.
     Know your producers and the nature of the relationship. Develop working understandings where possible.
     Understand the amount of influence you have and the guidance and support you can provide to control what you receive.
     Make sure you receive enough contextual information, or can create it during acquistion.
     Define an exit plan where possible.
  • Have you got a skills gap?
     Map existing roles and responsibilities.
     Identify gaps or unrealistic expectations by consulting community team profiles and job descriptions.
     Decide whether the gaps or bottlenecks can be addressed by training for existing people or hiring new posts.
     Understand willingness to change - whether you can stop doing things you do now and change job roles.
     Define a skills roadmap showing development over time. Include succession planning.
  • Have you got the infrastructure you need?
     Ingest - tools for characterisation, fixity, etc.
     Store - capacity, understanding growth, redundancy/backups
     Access - user requirements, interfaces for discovery/rendering, accessibility
     Prioritise your implementation with a clear roadmap. Don't try to do everything at once!
  • What are the access conditions affecting nature of resource?
     Determine IPR and sensitivity issues. Are they known or do they need to be reviewed?
     Ensure that depositor condition are clear (closure periods or embargos, reproduction rights, etc.)
     Define use cases. Define user requirements (as far as they can be anticipated). For example authenticity.
     
  • What is the condition of the 'stuff'?
     Know what you need to know - how much detail?
     Know what you don't need to know. What is enough information?
     Think about complexity/diversity, volume/growth
  • What are the bit-level problems?
     Save the bits!
     Find fragile media. Legacy devices, or short-lifecycle (e.g. floppy disk, CDs/DVDs, flash drives)
     If you have large files, understand if they have to be moved around, this can be problematic.
  • What are the content-level problems?
     Identify the variety of formats, and number of files in each format
     *use format identification tools
     
     Determine the problems that these formats cause:
     *decide the level of QA you can realistically achieve
     
     **pro-active (checking all files and formats)
     ***approaches: consult the community format registries, open every file, find software packages
     
     **reactive (provide files as-is and wait for problems to be reported)
     
     Decide what degree of stabilisation of assets is required via migration/emulation etc.