Difference between revisions of "CURATEcamp DLF 2012 Discussion Ideas"
From CURATEcamp
Robin Dean (talk | contribs) (→Fighting the "One Tool to Rule Them All" Mindset) |
Robin Dean (talk | contribs) (→Fighting the "One Tool to Rule Them All" Mindset) |
||
Line 35: | Line 35: | ||
* managing any preservation repository takes resources, so it's difficult to have more than one. Have one repository with multiple access/view layers. | * managing any preservation repository takes resources, so it's difficult to have more than one. Have one repository with multiple access/view layers. | ||
* Managing/displaying many different types of descriptive metadata--do you need multiple tools to do this? | * Managing/displaying many different types of descriptive metadata--do you need multiple tools to do this? | ||
+ | * The discovery layer is going to be Google! (or other search engines) - use RDF/schema.org and focus on how to expose metadata as broadly and usefully as possible | ||
Cylinders of Excellence: living with multiple systems (interoperability, one system to rule them all?) combatting "one tool" philosophy (three tools: DAMS for simple items, repo for authorial/ETD workflow, GIS data somethingsomethin'), how not to shoehorn everything (platform/layers vs. monolithic) - especially issues with multiple workflows - 18 | Cylinders of Excellence: living with multiple systems (interoperability, one system to rule them all?) combatting "one tool" philosophy (three tools: DAMS for simple items, repo for authorial/ETD workflow, GIS data somethingsomethin'), how not to shoehorn everything (platform/layers vs. monolithic) - especially issues with multiple workflows - 18 | ||
Revision as of 19:50, 3 November 2012
Contents
Agenda
Contribution and Ingest: Lowering Barriers
- just-in-case vs. just-in-time metadata
- what's "good enough": department, creator, hit send?
- how can we get digital stuff with the minimum amount of effort?
- set up a pre-ingest staging area for review to make sure content is "repository worthy"
- build in metadata and structure requirements as part of data creation - "data counseling" for reuse
- your digital ingest backlog already exists, it's just distributed across your institution
- should it be the content creators' job to deposit? mediated deposit yields better results
- set minimum compliance requirements for researchers
- this is a "knowledge translation" problem--it won't be easy
- tempting to scale back to absolute minimums, but that's not a good long term solution for reuse, discovery. Need a better balance.
- Email and Dropbox submission: accounts/authentication already built in, why not use it?
- Do mediated deposit and self deposit need to be mutually exclusive? How about "mediate on demand"?
- Levels of Service: process and team to spec out how long ingest will take. Data prioritized by content type/project.
- Help clean up existing content, and apply "lessons learned" to make templates for future data/metadata creation
- Summary: long process with a lot of complexity - make small, incremental steps. It's OK to do what you can for now. Doing what you can is better than over-promising.
- recap of C4L 2011 discussion: why does ingest suck?
- promise of permanence sets up a barrier (forever is intimidating)
- perception that ingest makes objects less discoverable
- rights - need to be cleared before ingest?
- metadata - requires too much? need a way to ingest easily and augment later
- curation happens outside repository, preservation happens inside
- more content in staging area than the "actual" repository
- content creators don't have time to ingest
- lessons learned
Fighting the "One Tool to Rule Them All" Mindset
- need to understand what each tool does well and its limitations
- the only way to cope with the weaknesses in each tool is multiple access/use layers. interoperability is our job security
- what is the usefulness of the comparison matrix? really have to install and use the tools to evaluate them, but sometimes that isn't possible
- more useful to think about a "framework" than "tools" -- but it's hard to do anything without programmers. Is outsourcing/contracting really feasible?
- compare to the times when we only had an OPAC and that was good enough--then came ERMs, discovery layers
- managing any preservation repository takes resources, so it's difficult to have more than one. Have one repository with multiple access/view layers.
- Managing/displaying many different types of descriptive metadata--do you need multiple tools to do this?
- The discovery layer is going to be Google! (or other search engines) - use RDF/schema.org and focus on how to expose metadata as broadly and usefully as possible
Cylinders of Excellence: living with multiple systems (interoperability, one system to rule them all?) combatting "one tool" philosophy (three tools: DAMS for simple items, repo for authorial/ETD workflow, GIS data somethingsomethin'), how not to shoehorn everything (platform/layers vs. monolithic) - especially issues with multiple workflows - 18
- project is done, now what? - proving value of investment - ROI ALSO funding models for repository/curation services (grants, etc.)- 18
- long-term preservation of complex objects (16)
- UI/UX development and reuse (how to do this, formal roles, community development)- usage of curation tools by users (vs. curators) - 16
- bootstrapping repository services (getting started with minimal resources) curation & preservation in the wild (sans repo) - 15
- Has the digital realm affected our idea of what digital preservation means? selection (e.g. of content types) for digital preservation -
are we saving too much? who decides? - 15
- Gather round for demos at 3:30 - 25ish
- data model from UCSD (17)
- Wrap-up session: community-building: future of CURATEcamp, sustainability - 19
Topics
- linked data (7)
- digital curation
- records management
- metadata & authority control (10)
- long-term preservation of complex objects (16)
- data model from UCSD (17)
- bootstrapping repository services (getting started with minimal resources) curation & preservation in the wild (sans repo) - 15
- development trends
- standards
- data management tools & processes
- Cylinders of Excellence: living with multiple systems (interoperability, one system to rule them all?) combatting "one tool" philosophy (three tools: DAMS for simple items, repo for authorial/ETD workflow, GIS data somethingsomethin'), how not to shoehorn everything (platform/layers vs. monolithic) - especially issues with multiple workflows - 18
- expanding the value of library infrastructure/tools (business use, scholarship) - 12
- Contribution/ingest - 20
- Abstraction layer for repositories especially from early and/or bespoke systems - 2
- community development (e.g. Hydra project on top of not Fedora) - 15
- METS development - 1
- UI/UX development and reuse (how to do this, formal roles, community development)- usage of curation tools by users (vs. curators) - 16
- Has the digital realm affected our idea of what digital preservation means? selection (e.g. of content types) for digital preservation -
are we saving too much? who decides? - 15
- Now that the bits are preserved, how do we preserve behavior/experience - 7
- multi-institutional repositories (UC, CIC, etc.)
- Wrap-up session: community-building: future of CURATEcamp, sustainability - 19
- PREMIS for preservation metadata (user feedback, requests) and changes coming in PREMIS 3 - 4
- persistent identifiers, e.g., ARKs - 8
- Gather round for demos at 3:30 - 25ish
- service models for ingest: internal repos vs external or subject repos - 8
- project is done, now what? - proving value of investment - ROI ALSO funding models for repository/curation services (grants, etc.)- 18
- e-book preservation - 4
Timeline
- 09:00-09:40 Introductions
- 09:40-10:00 Break
- 10:00-10:45 Voting/Ranking
- 10:45-11:15 Session 1: Ingest Barriers
- 11:30-12:00 Session 2:
- 12:00-1:30 Lunch
- 1:30-2:00 Session 3:
- 2:00-2:30 Session 4:
- 2:30-3:00 Session 5:
- 3:00-3:30 Session 6:
- 3:30-4:00 Break
- 4:00-4:30 Demos
- 4:30-5:00 Wrap-up/Future of Curate Camp