Policy Guidelines for the
ScholarSpace Institutional Repository
Content and Collection
Defining Communities and Collections
Community Start Up Procedures
Community Responsibilities and Rights
ScholarSpace Responsibilities and Rights
Submission Process
Authorization of Contributors
Submission Steps for Authorized Contributors
Copyright and Licenses – Intellectual Property Rights
Content Submitters Copyright
UHM Library license agreement
Copyright to theses and dissertationst
Metadata
Provenance data
Metadata elements
Workflow Guidelines
Contributors, Users and Privacy
Access, Storage and Preservation
Preservation Formats
Levels of Preservation
Persistent Identifiers
Withdrawal of items
Free and Fee Access
Backup and Recovery
Institutional repositories are often defined as “a set of services that a university offers to the members of its community for the management and dissemination of digital materials created by the institution and its community members.” ScholarSpace is a repository system at the University of Hawaii at Manoa (UHM) that enables us to capture, preserve and distribute the intellectual output of the university. ScholarSpace can serve as a resource for data, working papers, teaching materials, bulletins, as well as peer-reviewed articles.
The following are meant as guidelines for the types of collection content appropriate for ScholarSpace.
1. ScholarSpace primarily supports work that has been produced, submitted, or sponsored by UH faculty and staff. However, a Community can include papers from a conference they sponsor, which might include faculty from other institutions.
2. The work should be scholarly or research-based.
3. The work should not be ephemeral; deposits are intended to be permanent contributions
4. The work must be in digital form. If conversion to digital form is necessary, the E-Conversion Service might be necessary. Communities have the ability to establish collections of solely peer-reviewed articles if desired.
5. The work should be complete and ready for public dissemination before final submission.
6. Although the author/copyright owner retains copyright for all works submitted, he/she should be willing and able to grant UHM Library the right to preserve and distribute the work via ScholarSpace.
7. Established communities should strive for completeness in their collections. For example, if a work is part of a larger series or set of related works, these other works should also be contributed so that as full a set as possible is offered.
8. ScholarSpace is not intended to be used for commercial purposes.
9. ScholarSpace can accept the following items:
1. At UHM, a ScholarSpace “Community” is an administrative unit that produces research, has a defined lead, has long-term stability, and can assume responsibility for setting Community policies. The following are examples of possible Communities: Colleges or Schools within the University; research centers; students depositing dissertations or theses; or faculty and students with a common academic interest. Each Community must be able to assign a coordinator who can work with ScholarSpace staff. Groups wishing to establish a ScholarSpace 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 because they do not constitute an administrative unit.
2. Each Community can contain one or more “Collections”. Communities can also contain Sub-communities, which in turn house Collections. For example the
1. Initial contact between the ScholarSpace staff and the prospective Community, and including the librarian liaison if applicable.
2. The ScholarSpace administrator demonstrates ScholarSpace to the prospective Community and provides information about the repository, policy documents, sample submission agreements, and workflow options.
3. Community chooses a coordinator to act as a liaison to ScholarSpace staff.
4. The community, in partnership with the ScholarSpace administrator, develops Community policy regarding submissions, access, content withdrawal, workflow, membership, and preservation strategies. A list of those members authorized to perform workflow steps should also be provided to the ScholarSpace administrator at this time.
5. ScholarSpace staff creates the Community, initial Collections and the corresponding interfaces in consultation with the Community coordinator. The ScholarSpace administrator then authorizes groups and individuals as outlined by the Community, and posts the final version of the Community policies, as well as written agreements between the Community and ScholarSpace on the Community webpage for future reference.
The responsibilities taken on by a Community are to
At the UHM, the responsibilities taken on by ScholarSpace is to
ScholarSpace at the UHM Library retain the right to
Each collection can have its own submission process. The community or collection liaison works with the ScholarSpace project to decide on the workflows they wish to use. IR Communities will be asked to sign a Memorandum of Understanding with the UHM Library.
1. Communities determine contributors for each Collection
2. Authorization set out in Community policies
1. Register with ScholarSpace and edit his/her user profile
2. Post a submission to a specified Collection
3. Enter metadata for a submission, using standard forms with Community-specific default values
4. Include additional metadata with a submission
5. Bundle multiple files of various formats in a single submission
6. Allow the system to identify formats of submitted files, with user override
7. Grant a non-exclusive license to the UHM Library to distribute a submission in accordance with the specified distribution policy and translate it for the purposes of preservation (See note 1: Are the submitters granting permission to ScholarSpace, the UHM Library, or UHM?)
8. Receive updates if an item is rejected or at the end if the item gets final approval.
9. View past and pending submissions in a personalized area called My ScholarSpace
1. Authors retain the copyright for all content posted in the repository. The author agreement specifies a nonexclusive right to use. This means the author is free to reuse the content elsewhere.
2. If a working paper is published in a journal—either in the same form or, more commonly, in revised form many journals allow the working paper to continue to be made available, especially when it is for educational/scholarly noncommercial use. Unfortunately, some journals do require that the working paper be removed. Others grant exceptions for something like the an Institutional Repository; they just need to be asked. It is up to the faculty member to check the terms of their agreement with the journal to see what is allowed. Individual journal policies vary widely. The RoMEO Project (Rights MEtadata for Open archiving) has compiled a list of many journals' "Copyright Policies" about "self-archiving."
3. If a submitter is interested in including a reprint of a journal article in his/her repository site, the faculty member should check their agreement with the journal to see if it is allowed. If it would not violate copyright, he or she is welcome to do so.
Non-Exclusive Distribution License
In order for UHM Library 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 the IR at _______________.)
By signing and submitting this license, you (the author(s) or copyright owner) grants to the University of Hawaii at Manoa (UHM) 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 UHM may, without changing the content, translate the submission to any medium or format for the purpose of preservation.
You also agree that UHM 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 UHM 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 UHM, YOU REPRESENT THAT YOU HAVE FULFILLED ANY RIGHT OF REVIEW OR OTHER OBLIGATIONS REQUIRED BY SUCH CONTRACT OR AGREEMENT.
UHM 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.
The collection liaison is responsible for ensuring compliance with publisher copyright issues. However, the ScholarSpace project will provide information and resources to help with this assessment.
The University of Hawaii Graduate Division statement on Intellectual Property is:
Please note the following exceptions:
* Funded Research — If a student develops materials with funding from a grant or contract, even partially, then provisions of the grant or contract may determine ownership of intellectual property. When material is developed under research contracts, it is essential to ascertain from the contract-granting agency its expectations with respect to the copyright of the material. In the case of dissertation research, the contract-granting agency must be apprized that publication of the dissertation is required. It is the student's responsibility to make arrangements with the agency.
* Work as UH Employee — If a student develops materials while working as a university employee or if the work involves more than incidental use of university resources, then the university may have a right to a share of the intellectual property. In addition, the student must disclose the development of the materials to the Office of Technology Transfer and Economic Development.
See: http://www.hawaii.edu/graduate/thesdiss/html/copypatent.htm
The IR policy tracks the following provenance data:
By “support” for a given metadata schema we mean that metadata can be entered into the IR, stored in the database, indexed appropriately, and made searchable through the public User Interface. 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.
The metadata elements in the table below are collected in the UH IR for the following reasons:
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.
At the UHM Library the ScholarSpace staff recognizes that Communities have very different ideas for how material should be submitted to the repository, 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 Library’s ScholarSpace 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 ScholarSpace, then assigned to appropriate roles. The following are typical Community representatives:
These roles in the IR support 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 |
Reviewer
permissions |
-
Can review content of all files submitted to collection |
Coordinator permissions |
-
Can edit metadata of all submissions to collection |
Metadata editor
permissions |
-
Can edit metadata of all submissions to collection |
ScholarSpace staff, under the advice of the Cataloging Department, will work with Communities to identify unique metadata needs.
Digital preservation is an evolving practice and standards are not yet in place. However, we commit to tracking the development of standards and issuing advisories to Communities who are submitting to the repository. The UHM Library implementation of the ScholarSpace system for our IR attempts to support as many file formats as possible. This system identifies two levels of digital preservation: bit preservation, and functional preservation.
1. 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.
2. 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 UHM Library, 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.
When a file is uploaded to the IR, we assign it one of those three categories. For all three levels 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.
Put simply, UHM Library' policy for file formats is:
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". 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 IR Format Reference Collection as listed in the table below. Unfortunately, this means that proprietary formats for which these materials are not publicly available cannot be supported in the IR. We will still preserve these files, and in cases where those formats are native to tools supported by UHM 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".
IR Format Reference Collection for UHM installation of ScholarSpace
In the table below, MIME type is the Multipurpose Internet Mail Extensions (MIME) type identifier. 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 the IR, so either "sample.XML" or "sample.xml" will be recognized as XML. Level is the IR's support level for each format:
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 |
|
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 |
The CNRI Handle System is used to assign persistent identifiers to all material posted to the repository. These identifiers are resolvable in perpetuity, and will remain valid even if content is migrated to a new system. This allows documents in the IR to be properly and effectively cited in other research.
1. The system may be unavailable on occasion for update purposes. However, the ScholarSpace system administrators will perform maintenance at times least likely to cause a disruption of services.
2. The ScholarSpace administrative team will provide regularly-scheduled backup with off-site storage to guarantee backup and recovery.