CIRCA:Needs Document Example

From CIRCA

(Difference between revisions)
Jump to: navigation, search
VictoriaSmith (Talk | contribs)
(Created page with '= The Needs / Requirements of the HuCo Hist Archive…= * by Sophia Hoosein == What (technological) capabilities do the archivers require of the platform of the HuCo Hist arc…')
Newer edit →

Revision as of 08:25, 25 October 2010

The Needs / Requirements of the HuCo Hist Archive…

  • by Sophia Hoosein

What (technological) capabilities do the archivers require of the platform of the HuCo Hist archive?

Preference for open source repository platform (this is a safer choice than a for-hire service due to the economic downturn) Preference for producing an archive in conjunction with U of A Libraries (there is the opportunity for a partnership with the U of A’s institutional repository Education and Research Archive; we can leverage the technology ERA uses) (this will most likely be the case) This should be a “living” archive as opposed to an open/shut project since historical documentation of digital humanities artifacts is an ongoing process Tightly controlled workflow deposit (deposits should be made only by authorized individuals) (i.e.) the archive should be mediated (and not user-driven) (thus, we will need to upload items to the archive)

Examples of documents that only archive administrators can see:
    • Minutes from meetings
    • Records in draft (these will not be searchable because the will not be ready for publication)

Possibility that users can download items from the archive Different tiers of “privacy settings” / access to archive materials depending on who is accessing the archive. (i.e.): (metadata) (the document itself) Level 1:

  • Users can locate anything where permission has been granted
  • Users can find and download documents
  • Users can search metadata
  • Level where in order to download docs the archive must provide a link to it

Level 2:

  • “CCID”-like protection
  • users have access to metadata
  • users can see that the archive contains certain documents (however certain users may not have access to certain documents due to permissions requirements)
  • users can follow links to certain documents in the archive (such that user can locate the document somewhere else)
  • embargos: users can read the metadata and perhaps and abstract

Level 3:

  • The archive contains the item(s)
  • Users can see that the archive contains the items
  • Users cannot download archive items
  • “CCID”-like protection

Ability to create collections within the archive (COLLECTIONS pertains to thematic organization of archive items, and different collections will have different features)

    • Visualizations will be a nice inclusion; it will be effective to plug in visualization ad analytical tools

Preference for the use of relative URLs (as opposed to absolute URLs) Which one of the following can we use with the ERA? And; Which method is recommended as best practice?

    • Resolver versus URLs
    • DOIs
    • URIs  emerging standards for creating identifiers (i.e. ISBN)
    • OpenURL

Use of social networking / public contribution tools:

    • Links to social networking tools should a user want to post a specific item in their social networking profile (i.e. Facebook, Twitter, Delicious, etc)
    • Discussion forums
    • Comments

A way to contact the archivers Wikipedia (how would this apply?):

    • Public editors: leave the archive open for everyone to contribute
    • Invite someone who is an authority on a field
    • versioning: if the archivers introduce the ability for people to edit, think of the pros and cons of this
    • Animoto?

Use of embargos Archive ideally should allow us to store different items in different parts of the archive Obtain a Creative Commons License Standard for entering metadata (What exactly do we need to put in each field?) Preferred method is EAD (Encoded Archival Description) We are still exploring / investigating the possibility of RDF BACK UP WORK!! (perform regular backups)

Personal tools