Why catalog my project in a library system?

You are going to be putting a lot of time and energy into creating this project; you want to make sure people can find and use it! Here are some of the reasons the library is a great way to help people find your scholarship:

• • Your project has a greater chance of showing up in Google search results and other data aggregation sites, such as the Digital Public Library of America and Europeana.
  • Your project has a greater chance of being findable in the future, since your data can be maintained and fixed as part of a library system. A standalone project is a unique exception that can be lost in the vast internet. The power of a library comes in grouping similar things together, usually through standardized keywords. Trust your local librarian when they recommend describing your project using certain keywords — this will help other people find it!
  • Your project can “live” digitally near other things that are like it (including books on the same topic) — which increases the chances that people can browse to it. If there are multi-language and/or multi-country components, the library’s specialized keywords can be all the more helpful and important. 
• NOTE: Different countries have different cataloging standards, and use different vocabularies. This is an area of discussion with your local librarians.

Key People and Roles

There are certain people who are vital to the success of this kind of project. These people will help you create three things:

1. the live version of your project 
2. an archived version of your project 
3. catalog records pointing to the live and/or archived versions of the project.

The people and job roles who have the necessary expertise may cross multiple categories described below. Depending on the institutional context, these skills may also be distributed in different ways. For example, it is likely that library and technology professional collaborators will have expertise in some of the research activities. It is important to fully document each person’s contributions within the project to avoid assumptions about who does what work and to avoid reinscribing harmful hierarchies of labor within academia. 

Who oversee the project content and technical project creation. Depending on the project, there may be several people who attend to these areas. Research activities can include: archival research; recording audiovisual materials; creating captions, transcriptions, and translations; creating data and metadata schema; writing and editing textual content; evaluating technologies; designing interfaces and user experiences; project and relationship management; and many more.

• The intellectual work of a digital project, particularly a collaboratively created one, looks dramatically different from the work of a monograph. Though there can be overlap such as essay writing or research, it is best to recognize that intellectual contributions to digital projects will take different forms and to recognize and properly credit the labor and people. 

Reference or liaison; cataloguing or metadata; archives or special collections; and potentially digital scholarship librarians may be a part of your project team. Depending on your project, you may also work with another specialist librarian, like a copyright, map, or data librarian. Titles, job descriptions, and the division of labor varies from institution to institution, so it may take a little time to find the right group to collaborate.

• Digital scholarship librarians are newer roles within libraries and not every library will have one. This type of work can also go by different titles: scholarly communications, digital humanities, digital projects, digital initiatives, etc.
• If there is no single obvious person to talk to first, start with a reference or liaison librarian.

Instructional or academic technologists, web designers or developers, and systems administrators may have a role in the conversation. They will be important for helping to understand what the larger technology ecosystem is for the institution and what resources (server space, platform, maintenance, security and privacy, etc.) the digital project needs to stay viable for the life of the project. Titles and job descriptions vary from institution to institution, so it may take a little time to find the right group to collaborate. 

Three aspects of your digital project

Note: librarians, archivists, cataloguers, IT people, and researchers tend to have different definitions for “archive,” “collection,” etc. Agreeing on a common vocabulary and/or having 1-2 people who can communicate with all parties is important for avoiding miscommunications. 

In this document, the term “archive” refers to a stable, permanent backup of the project; it is not referring to a collection of items within the live project.

1. The live project 

The live project is the main version of the site that you work on and update frequently. It is recommended that project collaborators create metadata or descriptive information for 1) the project as a whole and 2) the individual files and bits of content.  

What to ask your IT department

• How best to create an inventory of all types of files contained in the project (journal articles, audio files, audio transcriptions, original manuscript material, etc) and decide what file formats are best suited for website presentation versus what should be preserved as part of the archival record.  
• Your IT department may be able to help you think through the structure of the live project, including where to host files for streaming audio/video, photos, etc that are included in the site.

What to ask your Library

• Your library may be able to help you think through the structure and metadata for the live project as a whole.
• How best to create an inventory of all types of files contained in the project (journal articles, audio files, audio transcriptions, original manuscript material, etc) and decide what kind of metadata is needed to describe these files. 
  • Common metadata include: date created; author of the file; editor of the file; location; rights statement.

2. The archival version

It is recommended that project collaborators create metadata or descriptive information for 1) the project as a whole and 2) the individual files and bits of content. This can contain all the component files that are presented in the live project site. The archival files will be “final” and most likely not edited once archived. 

What to request be archived (may be your Library, Archives department, or IT)

• Any raw files associated with the project (mp3, mov, ogg, etc)
• Any transcripts, translations, captions, or other associated files
• A snapshot of the live project website at intervals (annually, biannually), which would allow researchers to reference the project at a specific point in its lifespan.

Whenever possible, all files should be saved in file formats that are most likely to endure over time and are not proprietary formats. For example, save a data file as a Comma Separated Values file (.csv) instead of as an Excel spreadsheet (.xlsx). 

3. Catalog record 

What goes in the catalog record? This would ideally point to the URL of the live site and the archival record of the project. It would contain project-level metadata such as: author(s), editor(s), contributor(s), funding sources, location, date, rights statement. 

Why isn’t there a single answer for how to catalog my project? The parameters for cataloging either the project at large or the items within the project will depend on where your project is being cataloged. We recommend following the standards of that system, and discussing how to best fit the project within those standards with the cataloguer and librarians. Spending time to think through and describe the project within the relevant standards may help your project show up easily in multiple different library systems.

What parts of your project will be cataloged? There is no single right answer for what gets cataloged. You will want to talk this through with your local partners early. Remember that different levels of specificity can be employed for cataloging the project, a sub-collection within the project (such as all the materials related to one organization), or a single item. Based on conversations with local librarians, you may choose to catalog formally only the project, or every single item.

• Ask your Library for (in order of priority):

• • A single, collection-level catalog record, submitted to OCLC. It should mirror as closely as possible the fields of the original record for Constellation of the Commons [LINK].
  • A single collection-level metadata record submitted to your local institutional repository or some other repository that is publically indexed and is discoverable by public search engines. It should mirror as closely as possible the fields of the original record for Constellation of the Commons [LINK].
  • Multiple item level records submitted to your local institutional repository or some other repository that is publically indexed and is discoverable by public search engines. It should mirror as closely as possible the fields of the original record for Constellation of the Commons [LINK].

Be aware that if your library submits items to the Digital Public Library of America (DPLA) or Europeana, that the items will be disaggregated as a project. This means that each item record should have all relevant information about the project as a whole so that people could browse back to it.

Roadmap for cataloguing your project

1. Find the librarians and IT collaborators who can help with cataloguing as early in the project as possible. It will likely take time to find the right people who have the right expertise, and to find time in everyone’s schedules to develop rapport. It is also very important to agree on the best times to develop the project. Normally people who work in IT or in the library do not have the same work and vacation schedule as a person who works teaching in a university
2. At the beginning of the project, start a draft inventory [LINK] of what the project will include: video files, audio files, images, texts, glossaries, etc. Decide what descriptive information/metadata is needed for each one and collect that information as you create the files. It is always preferable to do it as you go and be a little slower overall, than to have to go back right before it’s published and have a hard time finding the information. You must be willing to make changes in all phases of the project.
3. Look for the time to build and strengthen the team in human terms, not just professionally. Have regular conversations and check-ins about progress, workload, ideas, etc. with researchers, librarians, and IT people. Consider having both longer, formal check-ins, and also having smaller, more informal check-ins on an ad hoc basis. 
   • Talk about the project lifecycle as you all understand it: how long it will take to build the project and when the “go live” date is; how long it will be actively maintained and edited; options for cataloging and pros/cons of each one.  
4. Share sample files and records with library and IT staff so they can better understand the project and ask if a mockup of the catalogue and archival collections can be made. There will likely be negotiations here about metadata and at what level it is displayed (project level, file level, etc.).
5. Document and credit all members of your project team within the published version of the project. This will be an ongoing process; be sure to update the credits page as new members of the team join.
6. Complete the creation of the live project, archival version, and catalog record. Document clearly what the project lifecycle is anticipated to be including regular maintenance checks and creating snapshots of the live project site to be included with the archival version, and who will do the specific tasks. Set a follow-up meeting for approximately 1 month after everything “goes live” to ensure everything is working and to reflect as a group on the process. 

The questions you might be asked

• Where should the project “live” — a university-provided server or 3rd party hosting and servers? 
• What is the desired domain name (URL) for the project?
• What platform or frameworks are you using to build the project?
• What kind of server or web hosting do you need for the project?
• Who will be doing the web design and development to create the project? 
• What level of accessibility does the project need to meet?
• How long will you maintain the live version of this project?
• Who will maintain the technical aspects of the site (security, server, platform (theme and plugin) updates)? How will responsibility be divided between IT and project collaborators? 
• What happens to the project after it stops being actively maintained? How long do you expect it to stay usable?

• What is the title of the project as a whole?
• Who is the author of the project as a whole?
• Who published the project, and where?
• When was it published?
• What is a short (1-3 sentences) description of the project?
• What is the URL of the project?
• What is the project about (i.e. what is the subject of the project)?
• How long will you maintain the live version of this project?
• What property and accessibility license do you want to give the project (copyright, creative commons, ect)?

• Where should the project “live” — a university-provided server or 3rd party hosting and servers? 
• What platform or frameworks does the institution support for digital projects?
• What kind of server or web hosting does the institution support for digital projects?
• Are there any web design and development professionals who can support digital projects? 
• What level of accessibility does the institution support for digital projects?
• Who maintains the technical aspects of the site (security, server, platform (theme and plugin) updates) if the project uses institutional resources? How will responsibility be divided between IT and project collaborators? 
• What happens to the project after it stops being actively maintained? How long do you expect it to stay usable?

The vocabulary you need

Metadata: The description of an item (eg, a video interview) or a project. The metadata of a book would include the title, the author, and the date of publication. Both digital projects as a whole and a single item within the project have metadata associated with them.

OCLC: Nonprofit cooperative organization that runs WorldCat. Libraries must pay to become OCLC members in order for professional catalog librarians to submit records to WorldCat. 

WorldCat: Global library catalog, itemizing the collections of 72,000 libraries in 170 countries. Anyone can search WorldCat; only OCLC members can add to WorldCat.

Persistent (or stable) URL: In order to avoid the problem of links breaking quickly, there are ways that experts have found to make more stable URLs. Be careful of very long URLs, or a URL that has a ? or = in it. 

DOI: Digital Object Identifier. A DOI is a string of numbers and letters that will stay permanently attached to a document, regardless of what the URL is. You could think of this like a document’s Social Security Number: just because your address changes, you don’t need to get a new SSN.

Controlled vocabulary: Specialized keywords used to describe what a thing (e.g. project, item) is about. The benefit of controlled vocabularies is that they allow you to easily identify more things on similar topics. Libraries use many different types of controlled vocabularies.

Proprietary software: Software, such as Microsoft Word or Adobe Photoshop, that is created and licensed for commercial use. End users cannot copy, alter, or enhance the underlying source code that makes up the software. Often, these products or software services package data and material in proprietary file formats that are best or only usable in the official software. 

Open source software: Software, such as Libre Office and Moodle, that allows end users to copy, alter, and enhance the source code.  

Server: There are several kinds of servers. For constellation projects, you’ll be working with web servers which are a combination of hardware and software that stores and serves the data that make up the constellation website. 

Hosting: A service through which storage and computing resources are provided to present websites. Institutions and 3rd party vendors can provide hosting but there is often variation based on speed and server size needed. 

Wireframes: Draft website designs that present layouts of elements like buttons, navigation menus, text, header, footer, etc.

Web design: Work that focuses on the website aesthetic, layout of content elements, sitewide navigation, and can include some technical code work. 

Web development: Work that focuses on some design elements, but often has deeper technical involvement with the coding frameworks used to build the website. 

User interface: The most visible layer of a website: what a reader of the website sees and what they interact with to navigate the site. 

User experience: How a person interacts with the content and site interface. For example, a good user experience is one that people describe as “intuitive” because they did not experience much friction trying to find or do what they wanted. A negative user experience is when a person finds a site unusable and difficult to find or do what they wanted.

Accessibility: Web accessibility means that websites and the content displayed is developed so that people with disabilities can fully interact with what is presented. Designing websites for disabled people also benefits non-disabled site users, and increases the audience and usefulness of the project overall. Note: there are different legal requirements for accessibility by country.

Licenses for use and reproduction: The authorization that the owner of the economic rights of a literary, artistic, musical, audiovisual or software work gives to other people about what they can and cannot do with the work. Copyright – Copyleft –