Designing the Archive for SHRP 2 Reliability and Reliability-Related Data (2014)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

39 C h a p t e r 4 This chapter defines key system and user requirements that were used to build the Archive. These requirements were captured as user stories and developed on the basis of two workshops, conducted as part of the L13A project, which aimed to collect SME feedback on essential features of the Archive. This chapter begins with the results of the fea si­ bility study conducted under L13. Note that, while the fea­ sibility report did include a set of requirements, those requirements were written from the perspective of analyz­ ing the feasibility of building such a system and for determin­ ing whether various high­level architectural concepts were practical. Systems engineering (Haskins 2007) would suggest the creation of a Concept of Operations that scopes the goals and needs of the system. However, much of the intent of that work was accomplished in the L13 report; what was required was a set of needs that can be used as the basis for system development and validation. From these needs a set of requirements could be generated, which in turn would form the basis for system verification. For Project L13A, the needs were defined in a series of user stories. Each user story describes how a user interacts with the system. In systems engineering this is partially the function of documenting scenarios. In software development as practiced using agile methodology, user stories take the place of requirements and form the basis for system verification, since the verifica­ tion of the user story indicates the system accomplishes the described task. 4.1 System Overview At the highest level, the Archive system provides a web­based interface to users, from which it provides access to a variety of tools to search the data archives, acquire data, and sub mit data for inclusion in the Archive. A similar interface is provided to administrators, who have additional abilities, including review of submitted data and maintenance of the data and metadata in the Archive. Data are submitted by users and held separately until an administrator can exam­ ine and validate their format and contents; at that time those data may be moved into the data archive, where they will be available to the web server and thus other users. Fig­ ure 4.1 illustrates this very high­level view of the Archive system. 4.1.1 Types of Artifacts The term artifact in this document covers any stored digi­ tal objects (e.g., document, data set, computer code) in the Archive system that will be viewed and used by researchers. This document will refer to two types of artifacts: (1) pri­ mary SHRP 2 artifacts, and (2) user­submitted artifacts. Primary SHRP 2 artifacts (or project artifacts) are those from the SHRP 2 Reliability­related project teams and are the pri­ mary focus of the Archive system. User­submitted artifacts are secondary files, typically derived from the primary arti­ facts, which Archive users can submit to the Archive system as part of the collaborative research process. Primary SHRP 2 artifacts and their related metadata are the foundation of the Archive system. As of the date this report was written, the L13A team decided not to let regular users submit any non– project artifacts due to security and privacy concerns. As a result, no user­submitted artifact has been uploaded into the system. 4.2 roles Four major user roles are envisioned for artifact ingestion: administrator, principal investigator (PI), registered user, and guest. To support different roles for different artifacts or proj­ ects, these roles are associated with individual user accounts. Table 4.1 compares user roles for the Archive system. System and User Needs and Requirements

40 4.2.1 Administrator The administrator role is performed by the project manage­ ment members of the Archive system management team. The administrator’s role serves the following functions: • Archive setup. Administrators define the system processes (e.g., access policies, ingestion process), specify metadata attributes and relationships, and define user roles. Admin­ istrators also create the Archive folder structure that stores the artifacts, generate initial metadata describing Archive folders, and test the artifact and metadata submission UI process. • Access and content moderation. Administrators work with project teams to determine the list of artifacts to be submit­ ted for each project; perform quality/content control checks of submitted artifacts and metadata; and moderate user profiles, roles, and comments. Administrators have the final authority to approve and accept artifacts (if needed) and metadata. • System monitoring. Administrators are responsible for reg­ ularly monitoring system health and usage statistics, allo­ cating information technology (IT) resources to address areas of concern, providing technical support to users on an as­needed basis, and creating regular preservation plan­ ning reports (~ every 3 to 5 years). • Preservation of PII. Administrators have to make sure no PII data are shared with the public via the Archive. 4.2.2 Registered User Each registered user creates a user account, which contains a minimum of information: userID, password, and e­mail address. The e­mail address of the user is verified during the User Administrator Data Archive Holding Pen Web Server Administrative Tools Figure 4.1. Archive system high level. Table 4.1. User Roles Role Guest Registered User Principal Investigator Administrator Download artifacts 3 3 3 3 Search and visualize artifacts 3 3 3 3 Participate in the discussion 7 3 3 3 Upload artifacts from the web page 7 7 3 3 Delete artifacts 7 7 3 3 Permanently delete artifacts from Archive 7 7 7 3

41 registration process. Users may choose to store additional information in their user account. Registered users can view pages, download artifacts, and write comments. Their user account keeps track of their com­ ments and file uploads. These users can edit metadata only on artifacts that they have uploaded. 4.2.3 Principal Investigator Principal investigators are registered users who can upload primary SHRP 2 artifacts. A PI takes on the role only for those artifacts that he or she uploads to the Archive system. There can be only one PI per artifact in the Archive. The PI is respon­ sible for preprocessing the artifact, creating the mandatory metadata associated with the artifact, and completing the artifact submission process. The PI is also responsible for performing a formal quality control check of the artifact and metadata after completing the ingestion process, to ensure high quality of submitted data and to minimize the burden of quality assurance on the administrator. The PI can also monitor comments and other collaboration on the artifact over time and update metadata to address any concerns raised by the user community. 4.2.3.1 Creator The notion of creator is conceptual and has not been used as a distinct user type in the Archive because, from the Archive sys­ tem’s point of view, the creator and the PI are the same. They are registered users of the Archive system who can upload arti­ facts. The only difference is that a creator can be someone other than the PI. The creator is assigned by the PI or SHRP 2 to perform preprocessing and metadata information collec­ tion tasks on behalf of the PI. 4.2.4 Guest To create the most open system possible, the Archive was set up so that any Internet visitor may access the system as a guest. However, in an attempt to minimize spam and archive abuse, this role is limited to “read only” and is limited to view­ ing pages and downloading data. Without a user account to tie other activities back to, guest users cannot write com­ ments or upload files. 4.3 System Needs This section discusses the Archive operational goals, system needs, and user needs. Operational goals establish parameters and targets for system performance. Needs identify what the system needs to do: • System needs describe what the system needs to do to meet operational goals. • User needs describe what the system needs to do to satisfy users. The needs were developed on the basis of the comments gleaned from the June 2012 stakeholder workshop and proj­ ect revised work plan. They were written in a language com­ patible with Institute for Electrical and Electronics Engineers (IEEE) Standard 1362. While this document does not follow that standard completely [it is not a fully fledged concept of operations (ConOps)], maintaining some of the structure within the traditional ConOps allows cleaner traceability to requirements and subsequent needs validation and require­ ments (user story) verification. 4.3.1 System and User Needs 1. Accept data. The system needs to accept data from users. Data may be provided electronically through an upload of individual files, or loaded into the system by an admin­ istrator from physical media (e.g., a portable hard drive, optical media, memory key). This allows producers of test data to share their data with other users, and also allows users of that data to provide transformed versions of that data back to the community. This enables collabo­ ration, corroboration, verification, and other research activities, without requiring researchers to enter into a direct relationship. 2. Store data. The system needs to store data provided by users in an organized manner so that other users may access that data. Such storage needs to maintain the data in its original form and with access restrictions stipu­ lated by the provider, until such time as the data are no longer needed. This provides the essence of a long­term data archive. 3. Distribute data. The system needs to provide users the ability to download the data they select from the Archive. This includes the ability to download complete test data sets. Downloads will occur electronically and may be limited in speed by available communications band­ width both at the Archive and at the data requester. 4. Maintain metadata. The system needs to associate meta­ data with data sets and files. This data about the data allows users to associate characteristics with data sets and, in turn, enables multiple dimensionality of association between data sets, access rights to data sets, and search functionality. 5. Search for data. The system needs to provide a mecha­ nism for users to search through available data. This mechanism allows the user to input criteria, and the sys­ tem will then provide a list of data that are relevant to those search criteria, which the user can then examine and download. 6. Site navigation. The system needs to provide a logical orga­ nization of the data archive and collaboration website. This

42 allows users to browse available data and discussions. Essentially, this means developing the data archive site in a modern style that is easy to navigate. 7. Allow modification of metadata. The system needs to allow users to modify the metadata associated with data sets and files. This function may be restricted based on user permissions. It allows enhancement to and correc­ tion of metadata. It also provides for the possibility of expanded definitions of metadata, which is relevant for those data sets whose formats have not yet been defined. 8. Allow data review. The system needs to provide a staging area for data input, where an authorized user can review submitted data and determine if it is acceptable for dis­ tribution. This allows quality control over data inputs. This implies an administrator or content manager role needs to exist to examine the data and determine its acceptability. 9. Organize data. The system needs to provide tools that allow users to organize data, so that data sets and files may be located, associated, and downloaded. This includes linking data to external data sets. This is subtly different from metadata associations, though the implementation may use similar or the same mechanisms if appropriate. Data set and file association should be available only to users permitted to manage site content. 10. Backup. The system needs to provide a backup of itself— including its configuration, functionality, and all stored data—to a remote location, so that in the event of a hard­ ware failure the system may be restored. 11. Predictable performance. The system needs to provide its services in a predictable fashion commensurate with similar services offered by other facilities. This manages user expectations. 12. Expandable. The system needs to be able to expand its storage capacity to accommodate more and larger data sets (at least 50 TB of data). This allows the system to grow and be maintained over the projected system lifetime. 13. Service. The system must be able to expand its storage capacity without disrupting services to users. This allows system upgrades without downtime and enables the sys­ tem to cope with changing storage requirements as noted in Need 12. 14. Extensible. The system must be able to support new data management technologies as those become available. This means it must be architected in such a way that data management functionality may be isolated and replaced. This allows the administrator of the data archive to extend the system’s capabilities over time. 15. Encryption. The system needs to provide the ability to encrypt any data that it exchanges, including administra­ tion exchanges, data storage, and data dissemination. This secures data and information exchange, which may be a requirement for some data sets in the future. 16. Compression. The system needs to provide the ability to (losslessly) compress any data that it exchanges, including during storage and dissemination. This frees up network bandwidth, thus reducing overall system costs. 17. Logging. The system needs to log auditable system con­ figuration and performance information. This informa­ tion may also be presented to permitted administrative users. Events to be logged include artifact ingestion pro­ cess errors, system warnings, and system statuses. 18. Availability. The system needs to be designed to be 100% available, operating with no scheduled downtime, except in the case of short outages for system updates and longer outages due to an occasional rebuild. 19. Data submission testing. The system needs to provide tools that analyze data sets for administrator­specified criteria. This allows the administrator to analyze the type, format, and size of submitted data and provides a measure of quality assurance. 20. Maintain users with individual permissions. The system needs to provide a means to distinguish user roles and per­ missions. This allows different users and user classes to be created with varying degrees of control over the system. 21. Robustness. The system needs to continue to operate dur­ ing a single failure instance. This implies the use of failover or fault­tolerant implementation and ensures continued availability. 22. Administration. The system needs to provide manage­ ment capabilities to administrator accounts. These abilities allow the administrator to configure the sys­ tem; to manipulate files by moving them, deleting them, or modifying their metadata; and to edit other user accounts. 23. Facilitate collaboration. The system needs to provide facilities that encourage collaboration between test data users. These collaboration facilities are intended to foster communication between researchers and to improve the quality of research and dissemination of relevant results. 24. Visualization. The system needs to provide visual mecha­ nisms for viewing subsets of the data it stores. This should be available from search or other navigation means and should also present the user with images of geographi­ cally referenced data. 4.3.2 Assumptions and Constraints It is assumed that ingestion would be accomplished with an API. Constraints would be the following: • Ingestion constraints. User­data ingest must support HTTP. • Metadata standards. Metadata must be developed according to a documented standard.

43 • System backups. System backup formats must follow a documented industry standard. • Administration security. Administration functionality must be provided over a secure connection except for those instances when such a connection is unavailable. • Interface documentation. All interfaces and backdoors must be documented. • Parallelism. The system must allow multiple files to be accessed simultaneously. • System hardware constraints. The system’s environmental footprint must be quantifiable in terms of power, floor space, and cooling if a dedicated (non–cloud­based) solu­ tion is chosen. 4.4 high-Level System Features Not simply a data warehouse, the SHRP 2 Archive does much more. It is a user­interactive repository that enables upload­ ing of artifacts, searching with results arranged by list or map, and bulk and subset downloading of artifacts (see Figure 4.2). Also, the Archive system is a user­friendly toolset that facili­ tates visualizations of user­selected data and collaborations between multiple researchers. Although it is being designed to ingest all artifacts created by the Reliability focus area– related projects, it is purposefully not limited to only those projects. Indeed, the system has the capability to share other researchers’ new/transformed data and/or work products of any origin that are related to travel time reliability. 4.4.1 Upload The SHRP 2 Reliability Archive’s ingestion wizard allows Reliability project leaders to upload artifacts along with their related metadata and data dictionaries. The system categorizes the artifacts into two general groups: data sets and non–data sets (e.g., documents, computer codes, video, pictures). Arti­ facts submitted under each category need to meet certain requirements. Therefore, the producer of an artifact has to preprocess it before submitting it into the system. 4.4.2 Search and Download The Archive provides faceted and text search tools to help users look for artifacts. The text search feature enables users to con­ duct content search within artifacts and metadata. In addition, the faceted search tool allows users to explore the Archive’s repository. Users can filter the search results by selecting vari­ ous related criteria. The system provides the search results on a map (Figure 4.3) and in a list. Once archived artifacts are found, users can download the desired objects along with their metadata and metadata doc­ uments (if available). Users also can download a subset of a data set. 4.4.3 Visualization The Archive system accommodates visualization schemes that provide valuable information interactively to users. Users will benefit from two types of visualization tools: map visualiza­ tion and data visualization. 4.4.3.1 Map Visualization The system has the capability to map the geolocation informa­ tion provided in a data set. The geofilter and map view capa­ bilities can help users explore sensor locations (Figure 4.4). 4.4.3.2 Data Visualization Users can explore and filter the content of a data set. They can make various 2­D plots (e.g., lines, points, bar, and column) Figure 4.2. Archive features.

44 Figure 4.3. Map search. Figure 4.4. Map visualization.

45 of any fields in the data set or a subset of a data set. The sys­ tem also has the capability to plot different series on a com­ mon plot. Furthermore, users can save and print the plots for future use (Figure 4.5). 4.4.4 Collaboration Registered Archive users can comment on project pages and artifact pages. They also can rate projects and artifacts. To comment on Archive pages and rate artifacts, users have to be registered. 4.4.5 Administration and User Profile Interface The Archive administrator is capable of granting access to users as well as adding, editing, and deleting site content. Through the administrator interface, the Archive administrator can also monitor the artifacts being ingested and moderate the com­ ments being submitted by the users. Using the user profile interface, users are able to change their password, modify and delete the artifacts that they sub­ mitted to the Archive, and edit a portion of their profile information. 4.5 Scenarios Scenarios are documented as user stories. To understand the system from the perspective of a user, user (U) terms are defined as follows: U1. Archive user. The Archive user wants services from the Archive system. These users may provide data to be shared, may download data others have provided, and may com­ ment on their own or others projects and data sets. U2. Archive administrator (administrator access control level). The Archive administrator operates the Archive system, manages data content, including metadata, and handles all IT administrative chores. U3. Archive system. The Archive system provides services to Archive users and responds to commands from the Archive administrator. U4. Other archive systems. Other archive systems interact with the Archive system by providing or acquiring data in automated fashion. 4.5.1 User Stories/Requirements A user story (US) is text written in everyday language that cap­ tures what a user does or needs to do as part of his or her job Figure 4.5. Data visualization.

46 function. User stories are employed in agile software develop­ ment methodologies as the basis for defining the functions a business system must provide and to facilitate requirements management. A user story captures the “who, what, and why” of a requirement in a simple, concise way. User stories are written by or for the business user as that user’s primary way to influence the functionality of the system being developed. User stories are written for the Archive system to provide a bridge between needs and requirements. They enable a more intuitive understanding of how users will interact with the system than is traditionally possible when examining requirements. User stories are traceable to needs, forming the basis for acceptance of the Archive system. The user stories were cate­ gorized into seven groups: general, ingestion, administration, search, download, collaboration, and visualization. 4.5.1.1 General US1. The Archive system provides information about the SHRP 2 Reliability focus area, SHRP 2 Reliability-related projects, and the artifacts associated with each project. US1.1. The user can search for an artifact at any point while on the website. US1.2. The user can browse through SHRP 2 Reliability- related projects. US1.3. The Archive system separately provides informa- tion about each Reliability-related project. US1.4. The Archive system provides general information about the SHRP 2 Reliability program and the Archive system. US1.5. The Archive system provides a thorough help document to guide the users. 4.5.1.2 Ingestion US2. The Archive user can submit artifacts to the Archive system. US2.1. The Archive user submits artifacts to the Archive system along with associated metadata. The user needs to meet the requirements specified in the Archive’s ingestion procedures. The Archive system accepts arti- facts and associated metadata and storage parameters as noted through the portal interface. The process of preparing and submitting an artifact to the Archive is called the ingestion process. US2.2. During the ingestion process, the user can save the submitted information at any step before continu- ing to the next step. The user can also save and exit the ingestion process at any time. US2.3. If needed, the user can also attach any related document that provides extra information about the artifact (e.g., data dictionary). US2.4. The Archive system provides confirmation to the Archive user of a successful submittal. US2.5. The Archive system processes the artifacts submit- ted by the user and logs both successful and unsuccess- ful submissions. US2.6. The Archive system notifies the administrator once an artifact is submitted. US3. The Archive administrator approves/rejects artifacts for archiving. US3.1. The Archive administrator verifies the content (making sure the content is appropriate) and approves/ rejects the artifact. The Archive administrator also veri- fies content of the metadata and makes sure the artifact does not contain PII. US3.2. On successful submission of the artifact and approval by the administrator, the Archive automati- cally checks and verifies the artifact (data structure and format). US3.3. The provider will be notified of the result of the verification process. US4. The Archive system stores the digital objects. US4.1. The Archive system stores the artifacts in the per- manent storage. US4.2. The storage archive must be organized so that Archive users can locate digital objects and determine associations between artifacts and projects. US4.3. The users should be able to visualize selected por- tions of data sets. US4.4. The permanent storage archive must protect against data loss. US4.5. The storage archive must not allow any changes to the SHRP 2 primary artifacts by the Archive user. Only the administrator and creator have the authority to delete a SHRP 2 primary artifact and modify the meta- data. The administrator receives a notification when a creator deletes one of his or her artifacts. The archival storage may be physically and logically distributed but must appear to Archive users as one archival system. 4.5.1.3 Administration US5. The Archive user registers with the Archive system. US5.1. The Archive user acknowledges a terms of use agreement and provides a userID, password, and con- tact e-mail. The Archive system creates an account for the Archive user and provides an e-mail confirmation. The Archive user is then able to use the Archive system to view and download artifacts and comment on artifact pages. Registering as a user is only needed to make comments (i.e., read and write access). No registration is needed to search, view, and download artifacts as a guest (i.e., read-only access).

47 US6. The Archive administrator deletes/updates artifacts. US6.1. The Archive administrator must be able to delete/ replace/update artifacts and their metadata. US7. An Archive PI cannot permanently delete SHRP 2 primary artifacts. US7.1. Under no circumstances can an Archive user per- manently delete SHRP 2 primary artifacts. A PI can only request permanent deletion. US8. An Archive PI updates only artifacts that he or she submitted. US8.1. A PI must be able to update metadata. US8.2. A PI can request deletion of an artifact. US9. The Archive administrator manages added capacity. US9.1. The Archive administrator adds additional storage capacity to the Archive system. The addition of the stor- age capacity will not disrupt any ongoing Archive sys- tem operations. The additional storage capacity must be available to use immediately. If storage capacity must be replaced, it must be possible to move data off of the storage capacity to be replaced and onto another storage media. US10. The Archive system protects the artifacts against power disruptions and failures. US10.1. The archive system protects the digital objects in the permanent storage archive against power disruption and failure of a single storage component (e.g., one hard drive). US11. The Archive system replicates the artifacts. US11.1. The Archive administrator is responsible for configuring the parameters of artifact replication. The Archive system must be able to replicate artifacts to one or more additional storage instances to provide resil­ ience to site­level disasters. US12. The Archive system backs up the artifacts. US12.1. The Archive system is able to back up artifacts to one or more additional storage instances. The Archive system can provide a subset of artifacts to back up based on various parameters (e.g., timescale, names, area). The Archive system must provide the ability to save system configuration and system metadata to reconstitute sys­ tem recovery and reconstruction. US13. The Archive administrator restores digital objects from backup. US13.1. The Archive administrator is able to restore dig­ ital objects and their metadata from a backup. US14. Users can create an account. US14.1. Users can sign up to the system by providing their name and a valid e­mail address. US15. The Archive administrator manages user accounts. US15.1. The Archive administrator is able to create, mod­ ify, and delete Archive user accounts. US16. The Archive administrator manages user permis- sions. US16.1. The Archive administrator sets up the user per­ missions for users that have responsibilities with the Archive system. This includes the ability to submit SHRP 2 primary artifacts or user­submitted artifacts only. The Archive administrator also can grant full control of the system to another user. US17. The Archive administrator manages the Archive system. US17.1. The Archive administrator configures the sys­ tem and manages the Archive activities of digital object ingestion and metadata modification. These activities include • Starting and stopping Archive system services; • Updating and patching application and system software; • Moderating content; • Providing customer service; • Controlling access; and • Verification. US18. The Archive system determines and maximizes per- formance of the system. US18.1. The Archive system is responsible for determin­ ing and then maximizing the overall performance of the Archive system. To verify this, performance is mon­ itored and recorded, performance­related actions are initiated and recorded, and subsequent performance is monitored and recorded. The Archive administrator will be able to access the system performance report. US19. The Archive system can be easily expanded without service interruption. US19.1. The Archive system’s storage must be expand­ able while maintaining services to Archive users and the Archive administrator. US20. The Archive administer defines a project and focus area. US20.1. The Archive administrator defines a project and focus areas within the Archive system. This includes set­ ting up the project namespace, location in the Archive, and directory structure. 4.5.1.4 Search US21. The Archive user can search and discover Archive artifacts in the Archive system. US21.1. The Archive user can search for artifacts on the following criteria: • Metadata entry, • Content of documents, and • Location associated with artifacts within their metadata.

48 4.5.1.5 Download US22. The Archive user can download Archive objects. US22.1. Once archived artifacts are found, the Archive user can download the archived objects along with headings metadata. US23. The Archive system can compress artifacts. US23.1. The Archive system must have the capability to compress digital objects. This feature will be used for downloading large data sets. 4.5.1.6 Collaboration US24. An Archive user may comment on projects. US24.1. A registered Archive user can provide comments on a project page within the Archive system. The com­ ments can be part of a comment thread. The comments contain the Archive user’s name for reference. US24.2. A registered Archive user can rate a project or an artifact and provide feedback. US25. The Archive administrator may delete comments on a project. US25.1. The Archive administrator has the capability to delete comments on a project. US26. An Archive user may comment on an artifact within a project. US26.1. An Archive user can provide comments on an artifact page within the Archive system. The comments can be part of a comment thread. The comments con­ tain the Archive user’s name for reference. US26.2. An Archive user can rate a project or an artifact and provide feedback. US26.3. A registered Archive user can contact the admin­ istrator to report an inappropriate artifact. The adminis­ trator will be notified. The administrator needs to review the content immediately. US27. The Archive administrator may delete comments on an artifact. US27.1. The Archive administrator has the capability to delete comments on a project or an artifact. 4.5.1.7 Visualization US28. The Archive system allows an interface for visual- ization of the digital objects. US28.1. The Archive system needs to be able to provide an interface for visualization of the digital objects that can be used by a third­party front­end visualization application. US29. The Archive user can select and manipulate the visualization of Archive artifacts in the archive system. US29.1. The Archive system accommodates visualiza­ tion schemes that provide valuable information inter­ actively to the users. The users will benefit from three types of visualization tools: grid, graph, and map visualization. Filter US29.2. Users can filter data columns using number and text filters. For a given data set, filters can be activated on one or more columns simultaneously. The number filter allows users to specify a value or ranges of values for filtering. US29.3. Once filtered, users can download the filtered subset of the data file. Grid view US29.4. The user can explore the content of the data and can sort a data set by fields (columns) in ascending or descending order. US29.5. In grid view, the user can show and hide fields of data and arrange the fields on screen for easy view­ ing. Users can scroll down a page and navigate to other pages within the data set. Graph view US29.6. The user can make 2­D plots of any fields in the data set or any subset of the data set. US29.7. Users can choose the type of graph to plot from the following options: line, spline, area spline, column, bar, pie, scatter plot. US29.8. To allow comparison of different fields, the user can choose one field to be displayed on the x­axis and up to five fields to be displayed on the y­axis. Users can show/hide each data field displayed on the y­axis and remove any y­axis field from the plot. US29.9. The user can print the graph and save the graph as one of the following formats: PNG image, JPEG image, PDF document, or SVG vector image. Map view US29.10. If geoinformation is provided on the metadata, the user can search for artifacts on the map. US29.11. If geodata is included in a data set, the Archive system is capable of displaying the references on the map.