DSpace/Startup

From OpenWetWare

< DSpace
Revision as of 08:52, 22 June 2005 by Reshma P. Shetty (Talk | contribs)
Jump to: navigation, search

Contents

Overview

Based on some questions from Sri, I started looking into MIT's DSpace more closely. DSpace is an institutional digital repository. Essentially a mechanism for preserving any type of scholarly digital work. Currently, each department has a community on DSpace but more communities can be added.

The reason I think DSpace might be useful to us is that it looks like it can actually solve many of the issues we were discussing in terms of making presentations, posters and publications available online. You can make certain collections accessible to either a specified group of users, to the MIT community or to the public. You can also submit any sort of digital item like pdfs, movies, code etc. For instance, Sri was saying that he was interested in possibly making Tabasco available through DSpace. My impression is that they are happy to work with us on setting up a DSpace community for synthetic biology.

Advantages of DSpace

  1. It is an institutional repository and therefore should be more stable than say a lab website.
  2. You can control access to works. This means it should be straightforward to initially post drafts for the group to review and later make them publicly accessible.
    Note: Although this is technically possible via DSpace, groups are strongly encouraged to release materials at least to the entire MIT community if not the world.
  3. It archives things for the historical record.
  4. Any sort of digital materials can be placed in DSpace.
  5. DSpace uses handles which are permanent. So we don't have to worry about changing URLs.
  6. We can link to things in DSpace via the wiki.

Demonstration of DSpace

Monday, June 6, 2005 at 1:15pm in 68-274

A tentatively scheduled meeting concerning DSpace at which Margret Branschofsky will do a demo. If there is time, it will be followed a by a discussion about whether having a DSpace community would be useful to us at this time. All are invited to attend. If you would like to attend and can't make it, please let me know ASAP so that I can reschedule. --Reshma 15:25, 3 Jun 2005 (EDT)

Some of the conclusions that the group came too after having this meeting are as follows

  1. DSpace is more useful as a backend than a frontend. DSpace is a good place to store and archive documents and then link to from the wiki, the lab website etc. However, as a frontend (i.e. a place on which to search for documents) it is not that useful.
  2. DSpace provides a convenient means for releasing information to the public and additionally provides a means for timestamping the release of that information that might withstand legal pressures.
  3. It is worth creating a separate community on DSpace rather than using existing Biological Engineering or CSAIL communities because it gives us control over the release of documents. Since documents can be crosslisted across communities and collections, this should not present a problem.
  4. Since we primarily intend to use DSpace as a backend for digital storage and preservation, the name of our community on DSpace is not necessarily that important. People will access the documents there through google searches, lab webpages and the lab wiki. Therefore, we can call the community Synthetic Biology even if not all the documents are immediately related to Synthetic Biology.
  5. DSpace is intended for finished materials not materials in the process of evolving. Therefore, it is not necessarily set up to permit new versions of documents to be added on. We can solve this problem by either labeling our documents as works in progress version 1, 2, 3 etc. Potentially existing items can be amended by adding new files. Also, we can partially address this issue by entering the metadata appropriately.
  6. Irrespective of our current need for a community on DSpace, it would likely be useful to us longterm and thus we might as well start a community now.

How to establish a community in DSpace

I went ahead and contacted DSpace to see what's involved in setting up a Synthetic Biology community on DSpace. Below is the information that Marget Branschofsky sent to me as well as my (off the top of my head) annotated answers. Please edit and comment as you like. If you think this is a dumb idea or more effort than it is worth, tell me that too. If everyone is in favor of creating a collection on DSpace and we come to a consensus about the answers below, then I can submit our answers to her and we can set up a meeting with Margret Branschofsky for her to instruct us on how to submit documents to DSpace.

Set Up Steps:

  • Head of community is made aware of the DSpace policies as outlined in http://libraries.mit.edu/dspace-mit/mit/policies/index.html.
  • Decide on structure of your community – whether there will be sub-communities, and what collections you will establish.
  • Decide which workflow steps you wish to establish for each collection (optional):
    • Reviewer (can accept and reject items)
    • Metadata Editor (can only change metadata before it is in DSpace)
    • Coordinator (can accept, reject and change metadata before item is in DSpace)
    • Collection Administrator (can change metadata after item is in DSpace)
  • Information below is sent to Margret Branschofsky at margretb@mit.edu.

Information Needed for Community Start-up:

Note: this information was sent to Margret Branschofsky to start the process of establishing a community on DSpace. I chose to keep the community as simple as possible with minimal administrative overhead. If the DSpace community is useful to us, then we can expand this adding more detailed descriptions, logos, subcommunities and collections. --Reshma 09:52, 22 Jun 2005 (EDT)

  • Name of Community Liaison

Reshma Shetty
(I'm willing to take on the administrative burden cause I think this is a good idea).

  • Community page:
    • Name of community
      Synthetic Biology
    • Description (optional)
      Synthetic biology refers to both (a) the design and fabrication of biological components and systems that do not already exist in the natural world and (b) the re-design and fabrication of existing biological systems.
    • Logo (optional)
      Maybe the image from the conference that is now on the parts registry?
      yeah, that's good. Jasonk 03:04, 27 May 2005 (EDT)
  • Sub-community pages (optional)
    None
    • Names of sub-communities
      I don't think we would need these to start with... can always add them if we have too much stuff later.Jasonk 03:04, 27 May 2005 (EDT)
    • Logo(s) for sub-communities (optional)
    • Descriptions of subcommunities (optional)
  • Collection pages:
    • Name(s) of collections within each community or sub-community
      Some ideas are papers, posters, presentations, software, movies, thesis proposals, working drafts, theses. Some of these should only accessible by Synthetic Biology people.
      1. Working drafts
      2. Talks
      3. Software
    • Logo(s) for collection(s) (optional)
    • Descriptions of collections(s) (optional)
    • Brief descriptions (one line) of collections to appear on community or sub-community page (optional)
  • For each collection:
    • Names and email addresses of submitters
    1. Thomas F. Knight, Jr. tk@csail.mit.edu
    2. Austin Che austin@mit.edu
    3. Julie Norville norville@mit.edu
    4. Reshma Shetty rshetty@mit.edu
    5. Drew Endy endy@mit.edu
    6. Jennifer Braff jcbraff@mit.edu
    7. Barry Canton bcanton@mit.edu
    8. Caitlin Conboy cconboy@mit.edu
    9. Jeffrey Gritton jgritton@mit.edu
    10. Heather Keller hkeller@mit.edu
    11. Jason Kelly jasonk@mit.edu
    12. Sriram Kosuri skosuri@mit.edu
    13. Francois St-Pierre stpierre@mit.edu
    14. Samantha Sutton ssutton@mit.edu
    15. Ilya Sytchev ilyas@mit.edu
    16. Ty Thomson tmt@mit.edu
    • Names and email addresses of people in workflow roles (optional): We would like everyone on the submitters list to be able to review and change metadata before and after item is in DSpace.
      • Reviewer (can accept and reject items)
      • Metadata Editor (can only change metadata before it is in DSpace)
      • Coordinator (can accept, reject and change metadata before item is in DSpace)
      • Collection Administrator (can change metadata after item is in DSpace)
        We should just agree on a metadata scheme and someone can be assigned to be the coordinator/editor, just to make sure that submissions have the right tags (for new users, people who forget, etc). I'd be willing to do it. Everyone could be assigned to the collection admin position, since i assume people wont change the tags unless they took care to make sure they are doing it right.Jasonk 03:04, 27 May 2005 (EDT)

Questions? Contact Margret Branschofsky at margretb@mit.edu or 3-1293.

Personal tools