DSpace Federation


 

 

 

 

 

 

 

 

 

 

 

 

 

 

DSpace Federation Home > Implement DSpace > Service & Support > Policy Planning > Policy Issues

DSpace Policy Issues

There are a number of important policy issues your institution will need to address when implementing DSpace. These issues vary from one site to another, but there are some common issues all sites must address.

The following lists policy questions the MIT Libraries staff addressed when building their DSpace implementation. We hope this list can serve as a guideline for your own universityís DSpace policy considerations.

These questions are offered only as a reference. We will add additional solutions from other universities as they become available.

What content is accepted in DSpace?

What digital formats does DSpace accept?

What is a Community in DSpace?

What responsibilities does a DSpace Community take on?

What rights does a DSpace Community retain?

What are the library's responsibilities?

What are the library's rights?

What are the university's responsibilities?

Will a Community be required to sign a Memorandum of Understanding (MOU)?

What is the policy on electronic signatures and click-through licenses?

What does the author or copyright owner agree to in the DSpace Distribution License?

What is DSpace's Privacy Policy?

What services will the library offer through DSpace and will they be offered for free or for a fee?

What type of preservation support does DSpace provide for content?

Can items be withdrawn from DSpace?

What are the required fields for a submission to DSpace?

What kind of workflow scenarios and community roles will be used in DSpace?


What sort of persistent identifiers does DSpace use?

What metadata standards does DSpace support? Can metadata be created using the [SCORM or VRA or FGDC or MARC or myOwnSchema]?

What provenance data does DSpace track?

What kind of authentication process does DSpace use?

What kind of service agreements exist for system availability?

Does DSpace accept metadata for items that are not submitted to or contained in the repository (virtual items)?

What policies should the library set for charging for access?



What content is accepted in DSpace?

These are the content policies that MIT Libraries use:

1. The work must be produced, submitted or sponsored by MIT faculty*.
2. The work must be scholarly or research oriented.
3. The work must not be ephemeral.
4. The work must be in digital form.
5. The work should be complete and ready for "publication".
6. The author/owner should be willing and able to grant MIT the right to preserve and distribute the work via DSpace.
7. If the work is part of a series, other works in that series should also be contributed so that DSpace can offer as full a set as possible.

* Library materials may be accepted under sponsorship of the University Librarian.

What digital formats does DSpace accept?
At MIT, DSpace accepts all manner of digital formats but provides differing levels of support depending on the format type (see What type of preservation support will be provided for content in DSpace?). Some examples of items that DSpace can accommodate are:

  • Documents (e.g. articles, preprints, working papers, technical reports, conference papers)
  • Books
  • Theses
  • Data sets
  • Computer programs
  • Visualizations, simulations, and other models
  • Multimedia publications
  • Learning objects

What is a Community in DSpace?

At MIT, a DSpace "Community" is an administrative unit that produces research, has a defined leader, has long-term stability, and can assume responsibility for setting Community policies. Each community must be able to assign a coordinator who can work with DSpace staff. Groups wishing to establish a DSpace Community that do not fall into this definition will be considered on a case-by-case basis. Individuals may not submit items without belonging to an established community in DSpace because they do not constitute an administrative unit.

What responsibilities does a DSpace Community take on?


At MIT, a DSpace community agrees to:

  • Arrange for submission and description of content
  • Decide policy regarding content to be submitted (within DSpace guidelines)
  • Make decisions about community and collection definitions and community membership
  • Notify DSpace of organizational changes affecting submissions
  • Understand and observe Institute policies relevant to DSpace, and educate community submitters regarding these policies
  • Clear copyright for items submitted when copyright owner is other than author(s) or MIT
  • Decide upon a submission workflow for each collection

What rights does a DSpace Community retain?

At MIT, a DSpace community retains the right to:

  • Decide who may submit content within the community
  • Limit access to content at the item level either to MIT only or to specific individuals or groups
  • Receive a copy of submitted content upon request
  • Remove items and collections (as outlined in "Withdrawal Policy").
  • Approve addition of or elimination of sub-communities
  • Customize interfaces to community content

What are the library's responsibilities?

At MIT, the MIT Libraries agree to:

  • Retain and maintain content submitted to DSpace
  • Distribute content according to community decisions
  • Preserve content using accepted preservation techniques
  • Notify communities of significant changes to content, e.g. format migration
  • If MIT Libraries cease to support DSpace, return collections to existing communities and transfer to MIT Archives collections of communities that have ceased to exist

What are the libraryís rights?

MIT Libraries/Dspace retains the right to:

  • Redistribute, sell or amend metadata for items in DSpace
  • De-accession items or Collections under certain circumstances - as outlined in "Withdrawal Policy".
  • Refuse items or collections not within the scope of DSpace as defined by
  • What content will be accepted in DSpace?
  • Renegotiate terms of original agreement with Communities
  • Perform appraisal for long-term archiving when Communities cease to exist or within thirty years of the creation of a Collection
  • Move Collections to reflect current agreement between DSpace and Communities
  • Migrate items for presentation purposes or at the libraryís discretion
  • Set quotas (size of files, number of items) to determine what constitutes free service and after which point to charge a fee.
  • Charge a fee for activities requiring extensive centralized support from DSpace (for example, for a large amount of de-accesssioning)

What are the university's responsibilities?

At MIT, the university is expected to:

  • Set policy at the Institute level regarding issues that affect Dspace, e.g. copyright rules, thesis requirements, etc.
  • Support functions mandated by existing policies.

Will a Community be required to sign a Memorandum of Understanding (MOU)?

DSpace Communities are not required to sign a Memorandum of Understanding or any other formal agreement with the Libraries, upon recommendation from our faculty advisory board.

What is the policy on electronic signatures and click-through licenses?

The DSpace system was built to require a click-through license based on advice from our legal counsel. Other options such as a license using electronic signatures would require development work to the system.

What does the author or copyright owner agree to in the DSpace Distribution License?

The MIT Libraries use the following license agreement in DSpace:

Non-Exclusive Distribution License

In order for DSpace to reproduce, translate and distribute your submission worldwide your agreement to the following terms is necessary. Please take a moment to read the terms of this license, fill in the information requested (and sign and submit this license to Dspace at _______________.)
By signing and submitting this license, you (the author(s) or copyright owner) grants to Massachusetts Institute of Technology (MIT) the non-exclusive right to reproduce, translate (as defined below), and/or distribute your submission (including the abstract) worldwide in print and electronic format and in any medium, including but not limited to audio or video.
You agree that MIT may, without changing the content, translate the submission to any medium or format for the purpose of preservation.
You also agree that MIT may keep more than one copy of this submission for purposes of security, back-up and preservation.
You represent that the submission is your original work, and that you have the right to grant the rights contained in this license. You also represent that your submission does not, to the best of your knowledge, infringe upon anyone's copyright.
If the submission contains material for which you do not hold copyright, you represent that you have obtained the unrestricted permission of the copyright owner to grant MIT the rights required by this license, and that such third-party owned material is clearly identified and acknowledged within the text or content of the submission.
IF THE SUBMISSION IS BASED UPON WORK THAT HAS BEEN SPONSORED OR SUPPORTED BY AN AGENCY OR ORGANIZATION OTHER THAN MIT, YOU REPRESENT THAT YOU HAVE FULFILLED ANY RIGHT OF REVIEW OR OTHER OBLIGATIONS REQUIRED BY SUCH CONTRACT OR AGREEMENT.
MIT will clearly identify your name(s) as the author(s) or owner(s) of the submission, and will not make any alteration, other than as allowed by this license, to your submission.


What is DSpaceís Privacy Policy?


The DSpace Privacy Policy at MIT states that the university is committed to preserving privacy. The personal information MIT receives through DSpace is used solely for purposes of the functioning of the system, and for the specific research purposes described below.

This system collects personal information from:
1. Users involved in the submission of DSpace content and metadata
2. Users who subscribe to the DSpace alerting service

Personal information collected by DSpace will not be used for any commercial or philanthropic purpose not directly connected with or approved by the Massachusetts Institute of Technology.

We do not disclose information about your individual visits to our site, or personal information that you provide us, such as your name, address, email address, telephone number, etc. to any outside parties except when we believe, in good faith (i) that the law requires it, or (ii) that disclosure is necessary to protect the rights and property of DSpace users.

DSpace data may be used by researchers of the HP-MIT Alliance's SIMILE research project under the conditions set forth in the "Terms for Use of DSpace Production Data".

Any DSpace records used in a publicly accessible forum, such as demonstrations, presentations, or research papers, will be scrubbed of specific references to real people and personal information.


What services will the library offer through DSpace and will they be offered for free or for a fee?


The DSpace Service is divided into two main areas:

  • Core Services: Available at no charge to Community members and consumers of DSpace content
  • Premium Services: Specialized services designed to meet the extraordinary needs of Community members and may be offered on a fee for service basis

DSpace Services
DSpace Core Services are comprised of two distinct but interconnected service elements, Interactive Services and Operations Services. DSpace Interactive Services offer a fully functional system that allows DSpace Community members and consumers of DSpace content to accomplish all tasks necessary to submit and access items in DSpace, as applicable. Additionally, MIT Libraries provide Operations Services to host and preserve faculty materials, establish and deliver ongoing support for DSpace Communities, respond to customer inquiries, and supply system monitoring, back up, and recovery.

From early feedback that we received, we anticipated that DSpace communities or individual faculty members may put extraordinary demands on the service such as sizeable storage requirements or assistance with specialized metadata creation. MIT Libraries plan to offer Premium Services to ensure that DSpace offers a full set of resources to meet faculty and researcherís needs and to manage the impact of these exceptional resource requirements on Libraries staff and DSpace resources. MIT Libraries reserves the right to introduce Premium Services fees as needed to aid in cost recovery.

Further definition of the Premium Services and market validation of the demand is being explored as DSpace is adopted campus-wide. Libraries traditionally have fostered open accessibility to information resources. Fee-based Premium Services are a departure from the typical approach to library services and one that requires careful consideration before implementing. The potential Premium Services areas identified thus far have been divided into the following categories:

  • E-Conversion Services: Creation of digital content from non-digital materials and custom, on-demand transformation of materials from one format to another
  • Metadata Services: Needs assessments, feasibility studies, advice on appropriate taxonomies, metadata crosswalks, metadata creation and support services, etc.
  • Custom Repository Services: Expansion of standard DSpace storage allocations to meet Community or individualís requirements that exceed normal limits
  • User Reporting Services: Research alert services, targeted notification services, hot topic citations, and custom reporting services


What type of preservation support does DSpace provide for content?


The MIT implementation of DSpace attempts to support as many file formats as possible.

DSpace identifies two levels of digital preservation: bit preservation, and functional preservation.

Bit preservation ensures that a file remains exactly the same over time ñ not a single bit is changed ñ while the physical media evolve around it.

Functional preservation goes further: the file does change over time so that the material continues to be immediately usable in the same way it was originally while the digital formats (and the physical media) evolve over time. Some file formats can be functionally preserved using straightforward format migration (e.g. TIFF images or XML documents). Other formats are proprietary, or for other reasons are much harder to preserve functionally.

At MIT, for the time being, we acknowledge the fact that the formats in which faculty create their research material are not something we can predict or control. Faculty use the tools that are best for their purposes, and we will get whatever formats those tools produce. Because of this weíve defined three levels of preservation for a given format: supported, known, or unsupported.

  • Supported: We fully support the format and preserve it using either format migration or emulation techniques.
  • Known: We can recognize the format, but cannot guarantee full support.
  • Unsupported: We cannot recognize a format; these will be listed as "application/octet-stream", aka Unknown.

When a file is uploaded to DSpace, we assign it one of those three categories. For all three level we will do bit-level preservation so that ìdigital archaeologistsî of the future will have the raw material to work with if the material proves to be worth that effort.

We are also collaborating with partner institutions (particularly Cambridge University in the UK) to develop new upload procedures for converting unsupported or known formats to supported ones where advisable, and to enhance DSpaceís ability to capture preservation metadata and to perform periodic format migrations.

Put simply, MIT's policy for file formats is:

  • Everything put in DSpace will be retrievable.
  • We will recognize as many files' formats as possible.
  • We will support as many known file formats as possible.


By "support", we mean "make usable in the future, using whatever combination of techniques (such as migration, emulation, etc.) is appropriate given the context of need". For supported formats, we might choose to bulk-transform files from a current format version to a future one, for instance. But we can't predict which services will be necessary down the road, so we'll continually monitor formats and techniques to ensure we can accommodate needs as they arise.

In the meantime, we can choose to "support" a format if we can gather enough documentation to capture how the format works. In particular, we collect file specifications, descriptions, and code samples, and make those available in the DSpace Format Reference Collection below. Unfortunately, this means that proprietary formats for which these materials are not publicly available cannot be supported in DSpace. We will still preserve these files, and in cases where those formats are native to tools supported by MIT Information Systems, we will provide you with guidance on converting your files into formats we do support. It is also likely that for extremely popular but proprietary formats (such as Microsoft .doc, .xls, and .ppt), we will be able to help make files in those formats more useful in the future simply because their prevalence makes it likely tools will be available. Even so, we cannot guarantee this level of service without also having more information about the formats, so we will still list these formats as "known", not "supported".

DSpace Format Reference Collection (MIT installation of DSpace)

In the table below, MIME type is the Multipurpose Internet Mail Extensions (MIME) type identifier; for more information on MIME, see the MIME RFCs or the MIME FAQ. Description is what most people use as the name for the format. Extensions are typical file name extensions (the part after the dot, e.g. the extension for "index.html" is "html"). These are not case-sensitive in DSpace, so either "sample.XML" or "sample.xml" will be recognized as XML. Level is DSpace's support level for each format:

  • Supported: We fully support the format and preserve it using either format migration or emulation techniques.
  • Known: We can recognize the format, but cannot guarantee full support.
  • Unsupported: We cannot recognize a format; these will be listed as "application/octet-stream", aka Unknown.
MIME type Description Extensions Level
Application/marc MARC marc, mrc supported
Application/mathematica Mathematica ma known
Application/msword Microsoft Word doc known
Application/octet-stream Unknown (anything not listed) unsupported
Application/pdf Adobe PDF pdf supported
Application/postscript Postscript ps, eps, ai supported
Application/sgml SGML sgm, sgml known
Application/vnd.ms-excel Microsoft Excel xls known
Application/vnd.ms-powerpint Microsoft Powerpoint ppt known
Application/vnd.ms-project Microsoft Project mpp, mpx, mpd known
Application/vnd.visio Microsoft Visio vsd known
Application/wordperfect5.1 WordPerfect wpd known
Application/x-dvi TeXdvi dvi known
Application/x-filemaker FMP3 fm known
Application/x-latex LateX latex known
Application/x-photoshop Photoshop psd, pdd known
Application/x-tex TeX tex known
audio/x-aiff AIFF aiff, aif, aifc supported
audio/basic audio/basic au, snd known
audio/x-mpeg MPEG Audio mpa, abs, mpeg known
audio/x-pn-realaudio RealAudio ra, ram known
audio/x-wav WAV wav known
image/gif GIF gif supported
image/jpeg JPEG jpeg, jpg supported
image/png PNG png supported
image/tiff TIFF tiff, tif supported
image/x-ms-bmp BMP bmp known
image/x-photo-cd Photo CD pcd known
text/html HTML html, htm supported
text/plain Text txt supported
text/richtext Rich Text Format rtf supported
text/xml XML xml supported
video/mpeg MPEG mpeg, mpg, mpe known
video/quicktime Video Quicktime mov, qt known


Can items be withdrawn from DSpace?


MIT foresees times when it may be necessary to remove items from the repository. It has been decided that under some circumstances items will be removed from view, but to avoid loss of the historical record, all such transactions will be traced in the form of a note in the <Description.provenance> field of the Dublin Core record. The content of the note should be one of the following:
" removed from view at request of the author"
" removed from view at MIT's discretion"
" removed from view at MIT Libraries' discretion"
" removed from view by legal order"

Since any DSpace item that has existed at some time may have been cited, we will always supply a "tombstone" when the item is requested, which will include the original metadata (for verification) plus one of the above withdrawal statements in place of the link to the object. The metadata should be visible, but not searchable. These items will also be made unavailable for metadata harvesting.


What are the required fields for a submission to DSpace?


While making decisions about each element, the MIT policy team kept in mind the following three reasons for collecting metadata:

  • To aid in the retrieval process
  • As a surrogate for the item (for instance, metadata harvesting by another system)
  • For use in later products (for instance, a bibliography in a particular discipline)

Metadata Element Element Description Policy
Contributor/Creator An entity primarily responsible for or contributing to the making of the content of the resource Required if available
Coverage The extent or scope of the content of the resource Not required
Date A date associated with the lifecycle of the resource System supplied if not provided by user
Description An account of the content of the resource Encouraged
Format The physical or digital manifestation of the resource System supplied
Identifier An unambiguous reference to the resource within a given context System supplied
Language A language of the intellectual content of the resource * Required (pull-down menu, including "non-text")
Publisher An entity responsible for making the resource available Not required
Relation A reference to a related resource Required if available
Rights Information about rights held in and over the resource Not required
Source A reference to a resource from which the present resource is derived Not required
Subject and Keywords The topic of the content of the resource Not required
Title A name given to the resource * Required
Type The nature or genre of the content of the resource Not required

* It was decided that only Language and Title could be enforced (by the system) as a requirement for completing a submission.



What kind of workflow scenarios and community roles will be used in DSpace?


At MIT, the library staff recognizes that Communities have very different ideas for how material should be submitted to DSpace, by whom, and with what restrictions. Who can deposit items? What type of items will they deposit? Who else needs to review, enhance, or approve the submission? To what collections can they deposit material? Who can see the items once deposited? All these issues are addressed by the Community representatives, working together with the Librariesí DSpace user support staff, and are then modeled in a workflow for each collection to enforce their decisions. The system has the notion of ìe-peopleî who have ìrolesî in the workflow of a particular Community in the context of a given collection. Individuals from the Community are registered with DSpace, then assigned to appropriate roles.

MIT has established four possible roles in DSpace as part of the workflow process: submitter, reviewer, coordinator, and metadata editor. An e-mail message is sent to each person at the appropriate step in the workflow, with authorizations set up in advance for each role.

Submitter permissions

- Can edit metadata for own submission
- Can upload files for own submission
- Cannot do anything once item is submitted

Reviewer permissions
(optional)

- Can review content of all files submitted to collection
- Can accept or reject all submissions to collection
- Can send a message explaining decision
- Rejection will stop submission
- Acceptance will let submission go to next step
- (Cannot edit metadata, or change files)

Coordinator permissions
(optional)

- Can edit metadata of all submissions to collection
- Can accept or reject all submissions to collection
- Can send a message explaining rejection
- Rejection will stop submission
- Acceptance will move submission to next step

Metadata editor permissions
(optional)

- Can edit metadata of all submissions to collection
- Submission automatically becomes part of DSpace after this step
- (Any approval would have happened before)



What sort of persistent identifiers does DSpace use?


DSpace uses the Handle System from CNRI to assign and resolve persistent identifiers for each and every digital item. Handles are URN-compliant identifiers, and the Handle resolver is an open-source system which is used in conjunction with the DSpace system.

Handles were chosen in preference to persistent URLs because of the desire to support citations to items in DSpace over very long time spans ñ longer than we believe the HTTP protocol will last. Handles in DSpace are currently implemented as URLs, but can also be modified to work with future protocols. Additional development work would be required to adopt some other form of persistent identifiers.

What metadata standards does DSpace support? Can metadata be created using the [SCORM or VRA or FGDC or MARC or myOwnSchema]?

By ìsupportî for a given metadata schema we mean that metadata can be entered into DSpace, stored in the database, indexed appropriately, and made searchable through the public UI. At the present time, this applies mainly to descriptive metadata, although as standards emerge it could also include technical, rights, preservation, structural and behavioral metadata.

Currently DSpace supports only the Dublin Core metadata element set with a few qualifications conforming to the library application profile. We are developing plans for how to support a subset of the IMS/SCORM element set (for describing education material) in the coming year.

HP and MIT also have a research project called SIMILE that is investigating how to support arbitrary metadata schemas using RDF as applied by the Haystack research project in the Lab for Computer Science and some of the Semantic Web technologies being developed by the W3C.

What provenance data does DSpace track?
The MIT policy tracks the following data:

  • Creation of item, collection, or community
  • Changes:
    • Accessibility (see withdrawal policy)
    • Format
    • Organizational
      • Per item
      • Per collection
      • Per community
    • Metadata
  • Withdrawal of item, collection, or community

Additional development work would be required to make changes to the type of provenance data collected.


What kind of authentication process does DSpace use?


MIT uses the following user authentication rules:

  • MIT-active people must use web certificates (so they donít need a separate password).
  • Non-MIT people should have DSpace accounts with passwords and ìemailî logins.
  • When users depart MIT, we can use their departure as a trigger event to switch them to an email login and password.
  • We should provide for the possibility that a legitimate active MIT user requires a password login (accessibility or other relevant, if rare, issues).

Additional development work would be required to make changes to the authentication process.


What kind of service agreements exist for system availability?


This issue will be addressed at an upcoming DSpace Policy Advisory meeting at MIT.



Does DSpace accept metadata for items that are not submitted to or contained in the repository (virtual items)?


This issue will be addressed at an upcoming DSpace Policy Advisory meeting at MIT.



What policies should the library set for charging for access?


This issue will be addressed at an upcoming DSpace Policy Advisory meeting at MIT.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

MIT Libraries Copyright © 2002-2007 MIT Libraries & Hewlett-Packard Company.
DSpace is a trademark of the Massachusetts Institute of Technology. See DSpace at MIT.
HP-MIT Alliance: vision, collaboration, invention