Difference between revisions of "Finding aids"

From CURATEcamp
Jump to: navigation, search
(Created page with "==Breakout Notes from CurateCAMP 2012== * reviewed strategies we had heard of: ** EAD-like semantics expressed in RELS-EXT ** EAD-driven finding aid sites that link to repositor...")
 
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Breakout Notes from CurateCAMP 2012==
+
=Breakout Notes from CurateCAMP 2012=
  
 
* reviewed strategies we had heard of:
 
* reviewed strategies we had heard of:
Line 13: Line 13:
 
** item view as javascript pane overlaid on finding aid (Indiana)
 
** item view as javascript pane overlaid on finding aid (Indiana)
 
** pulling finding aid context into repository item view
 
** pulling finding aid context into repository item view
 +
 +
= Notes from Board =
 +
*Don't unify well now
 +
*Ex-Libris trying to integrate EAD into their ALMA system, working on editing it in ALMA along with built in DC, MODS, MARC
 +
*EAD Expressible at many levels, flexible (collection stub, or series, box, folder, detailed item)
 +
*Hypatia Project Hydra for EAD
 +
**http://hypathia-demo.stanford.edu/
 +
*Rigid RELS =>Flex RELS?
 +
*Mashups across institutions?
 +
**e.g. - Jefferson Papers @ UVA & LOC
 +
*EACCF - Authority Work
 +
*Item to folder/box links when cols are rearranged
 +
*Archives online @ Indiana U.
 +
**From EAD using AJAX to call digital object
 +
**example: http://webapp1.dlib.indiana.edu/findingaids/view?docId=InU-Ar-VAA8687&doc.view=items
 +
*EAD going to 2.0 soon (scheduled for fall 2012?)
 +
*Using RDF to analyze FA's into their components
 +
**OAI-ORE
 +
*Separation between FA's & Physical Arrangement?
 +
*Preserving context and relationships is important
 +
*Building FA view on the fly
 +
*Users making their own relationships / contexts?
 +
 +
= Questions Asked (From memory) =
 +
#What advantage does EAD have over other potential solutions?
 +
#*It seemed as though the expectation was that archivists would have particular advantages in mind that EAD had over other potential solutions, but those who spoke said that the primary and potentially only advantage was that it was the format most popularly used, from their knowledge of other potential solutions.
 +
#What advantage might other solutions have over EAD?
 +
#*It seemed as though some solutions (I can't remember what) might be better suited to capturing the important relationships without limiting the EADs to:
 +
#**interacting within only their embedded system (ie- XTF).
 +
#**Not being able to be recompiled for different views
 +
#**It was also noted that, not only would it be good to be able to generate multiple views of the same information, but that there may be cases where archivists may want to provide the ability for user-generated views.
 +
 +
= Conclusions (From memory) =
 +
#It seemed as though there was a definite openness toward exploring solutions outside of EAD
 +
#There will likely be a new release of EAD toward the fall of this year - would be good to evaluate the new EAD within the context of the questions raised in this discussion.
 +
#It seemed like there were other solutions where relationships could be preserved while offering the potential for views generated on-the-fly.
 +
#*(<span style="color:red">what were these solutions?</span>)
 +
#Linked data makes it possible to harvest/present/mine information from many documents, including EAD and others. If we can collect and present information from many sources, then what are the other design factors that motivate us to use a particular document format or encoding for finding aids? That is, if aggregation and presentation is a given, then what should be consolidated (EAD) and what should be distributed (RELS-EXT style RDF)? I suspect that we want the encoding that best suits the finding aid authors, giving them a comprehensive view and powerful tools.

Latest revision as of 07:20, 26 May 2012

Breakout Notes from CurateCAMP 2012

  • reviewed strategies we had heard of:
    • EAD-like semantics expressed in RELS-EXT
    • EAD-driven finding aid sites that link to repository item view
      • loss of collection context after link
      • visitors who find the item via search engines are unaware of finding aid
    • identified that encoding/storage of finding aids is not important to users/creators
      • finding aid presentation matters
      • finding aid creation must be supported
      • RDF vs. EAD vs. ? doesn't matter as long as semantics are adequate
  • interesting finding aid implementations or intergrations:
    • item view as javascript pane overlaid on finding aid (Indiana)
    • pulling finding aid context into repository item view

Notes from Board

  • Don't unify well now
  • Ex-Libris trying to integrate EAD into their ALMA system, working on editing it in ALMA along with built in DC, MODS, MARC
  • EAD Expressible at many levels, flexible (collection stub, or series, box, folder, detailed item)
  • Hypatia Project Hydra for EAD
  • Rigid RELS =>Flex RELS?
  • Mashups across institutions?
    • e.g. - Jefferson Papers @ UVA & LOC
  • EACCF - Authority Work
  • Item to folder/box links when cols are rearranged
  • Archives online @ Indiana U.
  • EAD going to 2.0 soon (scheduled for fall 2012?)
  • Using RDF to analyze FA's into their components
    • OAI-ORE
  • Separation between FA's & Physical Arrangement?
  • Preserving context and relationships is important
  • Building FA view on the fly
  • Users making their own relationships / contexts?

Questions Asked (From memory)

  1. What advantage does EAD have over other potential solutions?
    • It seemed as though the expectation was that archivists would have particular advantages in mind that EAD had over other potential solutions, but those who spoke said that the primary and potentially only advantage was that it was the format most popularly used, from their knowledge of other potential solutions.
  2. What advantage might other solutions have over EAD?
    • It seemed as though some solutions (I can't remember what) might be better suited to capturing the important relationships without limiting the EADs to:
      • interacting within only their embedded system (ie- XTF).
      • Not being able to be recompiled for different views
      • It was also noted that, not only would it be good to be able to generate multiple views of the same information, but that there may be cases where archivists may want to provide the ability for user-generated views.

Conclusions (From memory)

  1. It seemed as though there was a definite openness toward exploring solutions outside of EAD
  2. There will likely be a new release of EAD toward the fall of this year - would be good to evaluate the new EAD within the context of the questions raised in this discussion.
  3. It seemed like there were other solutions where relationships could be preserved while offering the potential for views generated on-the-fly.
    • (what were these solutions?)
  4. Linked data makes it possible to harvest/present/mine information from many documents, including EAD and others. If we can collect and present information from many sources, then what are the other design factors that motivate us to use a particular document format or encoding for finding aids? That is, if aggregation and presentation is a given, then what should be consolidated (EAD) and what should be distributed (RELS-EXT style RDF)? I suspect that we want the encoding that best suits the finding aid authors, giving them a comprehensive view and powerful tools.