WISCONSIN DEPT. OF TRANSPORTATION
RFI 0508-DTSD – DTSD Interactive Engineering File Management System
State of Wisconsin
Department of Transportation (DOT)
Request for Information (RFI) #0508-DTSD
DTSD Interactive Engineering File Management System
Issue Date: May 8, 2014
Responses Due: June 10, 2014 at 2:00 PM CT
This Request for Information (RFI) is issued solely for information and planning purposes only, and does
not constitute a solicitation. Responses to the RFI will not be returned. Responses to this RFI are not an
offer and cannot be accepted by the State to form a binding contract. The State of Wisconsin is not
liable for any cost incurred by the vendor in response to this RFI.
Communications concerning this RFI may be directed to
Melissa Viken
Wisconsin Department of Transportation Purchasing
E-mail: melissa.viken@dot.wi.gov
4/17/2014
1|Page
WISCONSIN DEPT. OF TRANSPORTATION
RFI 0508-DTSD – DTSD Interactive Engineering File Management System
Table of Contents
Table of Contents ...................................................................................................................................... 2
Terms and Definitions ............................................................................................................................... 2
Purpose of the Request for Information................................................................................................... 2
Project Goals & Requirements .................................................................................................................. 3
Background and Current Operation.......................................................................................................... 3
Vendor Response ...................................................................................................................................... 4
Submitting a Response.............................................................................................................................. 8
Appendices................................................................................................................................................ 8
Appendix A - Requirements ...................................................................................................................... 8
Appendix B - Metadata Items ................................................................................................................. 14
Terms and Definitions
COTS
- Commercial off the Shelf
DOT
- Wisconsin Department of Transportation
DTSD
- Division of Transportation System Development
EDMS
- Electronic Document Management System
FC
- File Cabinet
RDA
- Records retention/disposition authorization
RFI
- Request for Information
RFP
- Request for Proposal
State
- State of Wisconsin
WisDOT
- Wisconsin Department of Transportation
The terms application, system, and solution are used somewhat interchangeably in this document.
Purpose of the Request for Information
The Wisconsin Division of Transportation System Development (DTSD) has an application called File
Cabinet (FC) to help manage their electronic documents related to transportation infrastructure
projects. File Cabinet was built and customized by IT staff and has been revised over 25 years to address
changes in business requirements and to address technology changes. The current platform upon which
File Cabinet sits is obsolete and a replacement product is needed.
4/17/2014
2|Page
WISCONSIN DEPT. OF TRANSPORTATION
RFI 0508-DTSD – DTSD Interactive Engineering File Management System
The purpose of this RFI is to gather information about solutions that will meet business needs, and
review a wide range of options. The knowledge of these options will aid in the development of a
strategic, long-term approach. Responses to this RFI will be evaluated and may be used to develop an
RFP to acquire a product and/or service that meets business needs and requirements.
Project Goals & Requirements
The RFI project team is charged with exploring solutions for replacing the current File Cabinet
application. The replacement application will need to perform the functions that DTSD currently relies
on File Cabinet to carry out and to perform additional functions that will be needed in the future. The
replacement solution will need to meet these requirements:
 Files and Metadata: Wisconsin’s transportation infrastructure project files, and the metadata
kept about the files, must be stored and readily available.
 Search/Select: There is the ability to list and choose files based on the files’ attributes.
 File Reporting/Display: There is the ability to select files for reporting chosen metadata and for
displaying files with and without redlined overlay.
 Move/Copy/Rename: Allow files to be duplicated, relocated, and renamed.
 Versioning and Archive: Allow copies of interim versions to be saved and archived for later
reference.
 Check In/Out: Allow users to quickly retrieve and store projects and files. To insure integrity of
the projects and files, restrictions are necessary for concurrent use of files.
 Access Control: Authorization to view and manipulate files is needed.
 User Interface: Web browser access is desirable for the proposed solution for both internal and
external staff. The DOT’s internal standard browser is Internet Explorer v10.
 Interface with Other Systems: The replacement application needs to successfully interface with
DTSD’s purchased and in-house applications/systems.
 Administration: Allow configuration of the replacement system.
 Migration: Migration assistance will be needed.
See Appendix A for more detail on the above requirements.
Background and Current Operation
The information below describes the nature, size, and scope of DTSD’s current operations and use of File
Cabinet. This information is not intended to be a complete description; rather it is to provide a general
sense of what a potential solution will need to provide for consideration.
DTSD works with state, local, federal units of government and non-governmental consultants, both in
Wisconsin and other states. DTSD utilizes custom developed and COTS applications that reside on
multiple platforms: client-server, web-based, and mainframe (z/OS). The business data does reside on
file servers, in Oracle (along with DB2, MS SQL Server), and with other types of data storage. DTSD
utilizes infrastructure and software supported by Wisconsin’s Division of Enterprise Technology and by
DOT’s Bureau of Information Technology Services, including: Windows Server 2008R2 Standard (moving
to Windows Server 2012), Windows 7, Microsoft Office products (such as Outlook), Microsoft
4/17/2014
3|Page
WISCONSIN DEPT. OF TRANSPORTATION
RFI 0508-DTSD – DTSD Interactive Engineering File Management System
SharePoint 2013, Red Hat for Linux, Adobe, and ESRI ArcGIS. Wisconsin uses purchased systems:
Bentley engineering products, AutoCAD engineering products, Axiom (dependent on MicroStation or
AutoCAD), Trimble Business Center, and BEM Systems PAECETrak.
DTSD also works with many in-house built systems. See the Information Requested, Interface with
Other Applications section below for more detail on these. Here is information pertaining to the inhouse built File Cabinet system:
 File cabinet is a client/server file management system with online and batch utilities. The files
are kept on file servers, and the metadata is kept in Oracle tables.
 File Cabinet interfaces with Bentley MicroStation.
 File Cabinet manages approximately one million files. These files may be the latest version or
previous versions. Critical to the metadata associated with these files, are descriptions of the
approximately 13,000 projects. The association between file names and project names are kept
in relational tables.
 Currently no zipped file exceeds 2 gigabytes. In the future, files may reach 5 gigabytes,
unzipped.
 File Cabinet-managed compressed files that use a total of approximately 207GB of disk space. It
is imagined this amount will increase by about 20 percent each year.
 There is approximately 2000 check in/out transactions per week. Counts for view and update
activities are not available.
Vendor Response
Response in General
Please respond to the following sections. Limit your response to 75 pages.
Company Information
1. Please provide complete information about your company. Include, but do not limit your
information to such topics that include how long you have been in business, your financial
reliability, the rate of growth and how your organization’s growth is managed, the experience
and turnover rate of your operational staff, information on your parent company (if such exists),
and how many mergers/acquisitions your company has been involved in.
2. Briefly summarize the scope of relevant products and services that your company provides.
3. Provide contact name(s) and information for questions Wisconsin DOT may have regarding your
company’s response to this RFI.
4. DTSD is a government division of WisDOT. Describe your experience with government clients,
or clients of similar size and complexity. Please indicate the types of products used by those
clients and how they relate in size, scope, and complexity to the product you are proposing.
5. Provide information on the success rate of similar implementations your company has
performed and information on the lessons learned from less-successful implementations.
Please include information on whether these implementations were completed on time and
within the budget initially proposed.
4/17/2014
4|Page
WISCONSIN DEPT. OF TRANSPORTATION
RFI 0508-DTSD – DTSD Interactive Engineering File Management System
Product Information
Please include in your response how your solution addresses the requirements; and be specific, giving
sufficient detail to explain the capabilities of your solution. If your response speaks to a subset of our
requirements, please also indicate how your product could integrate with other systems or make use of
another COTS product to form a complete solution. If you have other information you would like to
share that pertains to your proposed solution that was not mentioned in this document, feel free to
provide it in your response. When describing how your solution meets the requirements, please include
the information below.
General
1. Please provide complete information in your response that describes your product or service in
sufficient detail, i.e. hosted solution, cloud, etc.
2. Describe any limitations once the product is installed and operational.
3. Please provide a list of potential problems and risks that WisDOT may encounter if it adopts
your solution. Provide suggestions of how problems and risks would be mitigated. Describe the
standard warranty and post implementation support provided for your solution including how
you provide support.
4. Describe the testing, technical support, and maintenance services provided by your company.
Include support hours and service level agreement. Note: The proposed system will need to
comply with DOT maintenance and standards.
5. Describe your approach to error handling. Be specific.
6. Describe your plan supporting past, current and future solutions for file management. What
operating systems and other standard system products do you support and/or utilize? What is
the typical process for security patching and upgrades to new releases?
7. Please provide information on training and documentation that will be provided, and your
approach to training, i.e., computer based training, train the trainer, video, etc.
8. Describe the technology architecture of your proposed solution:
a. Describe the system requirements for your solution including, but not limited to:
i. Web/database/application servers (OS, CPU and required software)
ii. Server and desktop hardware requirements
iii. Supported databases
iv. Application development environment supported
v. Amount of storage required for a typical installation
b. Describe the hosting options
c. Describe the API interfaces / web services
d. Describe authentication and security
9. Identify the system solution's storage processes, back-up processes, and security measures to
ensure sensitive information is not compromised or removed by employees.
10. Provide information regarding transaction volumes of which your system is capable of along
with examples where it is being used to its maximum potential.
11. Would you be willing to provide a demonstration of your solution?
Files and Metadata
12. Describe your solution’s approach to handling project files:
a. Does it convert the file to an object and then as needed (such as for viewing), convert it
back to its native format?
b. Does it leave the files in their native format and process as files in a directory?
c. Are there other ways you can handle files?
4/17/2014
5|Page
WISCONSIN DEPT. OF TRANSPORTATION
RFI 0508-DTSD – DTSD Interactive Engineering File Management System
13. Describe how you manage file names. Do they include alpha, numeric and special characters,
and what is the maximum number of bytes a file name can be?
14. Describe your support for the capture and use of metadata and reference files.
15. Describe your support of designating and using work flows.
16. Describe your support of setting up and use of auditing. Provide an example if possible.
17. Describe if your solution can provide a pointer to the location of paper files; the electronic file
would contain the metadata for the paper file.
Search/Select
18. Describe the features of your application’s search and select functions.
19. Does your application allow for multiple files to be selected and a subsequent function be
performed?
File Reporting/Display
20. Describe reporting functionality your solution provides. Be specific regarding information
retained about files and describe if and how your product interfaces with other report generator
tools.
21. Describe the functionality and features of your application’s redlining function.
Move/Copy/Rename
22. Describe the features of your application’s move, copy and rename functions.
Versioning and Archive
23. Describe your application’s approach to versioning.
24. Describe how your application handles archiving.
25. Describe your RDA compliance capabilities.
Check In/Out
26. Describe the processes and features of your application’s check out function.
27. Describe the processes and features of your application’s check in function.
Access Control
28. Describe your approach for controlling file and metadata viewing and manipulation.
29. Describe how your solution authorizes and authenticates. Please include any federated
directory management the tool may provide.
User Interface
30. Describe in sufficient detail the user interface DOT would use to execute your application’s
functions.
31. Please provide a comprehensive list of system requirements for workstations and/or mobile
devices.
Interface with Other Applications
32. Describe in sufficient detail how your solution interfaces with other systems, both COTS and inhouse applications.
33. With which other electronic document management systems can your solution interface or use?
Administration
34. Describe how your product would handle DOT’s business requirements, including:
a. Does your product support the flexibility to customize the configuration? If yes, what
tools are needed to accomplish this? Are changes to the metadata allowed?
b. How do you support and manage customizations to your product?
c. Is your product flexible enough to allow for legislative mandates and changes? Describe
your proposed approach to system modifications. Include who and how these
modifications might be executed.
35. Describe a typical implementation, and provide an example of customer requirements including
skills sets that may be needed.
4/17/2014
6|Page
WISCONSIN DEPT. OF TRANSPORTATION
RFI 0508-DTSD – DTSD Interactive Engineering File Management System
Migration
36. Please describe your approach on how you would migrate the existing data from the File
Cabinet product.
37. Describe the tools that would be used to perform the data migration including files, metadata
and relationships. Include the approach you might take.
38. Please provide an estimate of time to implement to your solution. A range is acceptable, i.e. 6
months – 12 months.
Pricing Structure/Methodology
NOTE: Do not provide pricing or documents which contain specific pricing information.
1. Provide the company or industry model used for pricing in your response. Is pricing based on
transactions, storage volume, or some other metric(s)? Discuss the model used for services,
products, training, and support throughout the lifecycle of the solution.
2. Describe your methods for products and services acquisitions, price increases, invoicing, and
payments. Do you offer leasing and if so, how? Do you offer government pricing schedules?
3. What services or products fall outside of the typical contract that could be charged separately?
COMPANY/ORGANIZATION NAME
Name the person to contact for questions concerning this proposal.
Name
Phone
FAX
Address
City
(
(
Title
Toll Free Phone
Email Address
)
)
State
(
)
Zip + 4
DESIGNATION OF CONFIDENTIAL AND PROPRIETARY INFORMATION
List below any of the sections of the response deemed to be confidential or proprietary.
Section #
4/17/2014
Page #
Topic
7|Page
WISCONSIN DEPT. OF TRANSPORTATION
RFI 0508-DTSD – DTSD Interactive Engineering File Management System
Submitting a Response
Submit one (1) hard copy and one (1) electronic PDF version (on CD, DVD, or USB flash drive) to:
U.S. Mail:
Purchasing
WI Department of Transportation
4802 Sheboygan Ave., Room 751
PO Box 7396
Madison, WI 53707-7396
UPS, Fed Ex, etc.:
Purchasing
WI Department of Transportation
4802 Sheboygan Ave., Room 751
Madison, WI 53705
If you choose to hand deliver your response be aware of increased building security and that access to
WisDOT offices is restricted. Allow time for security clearance to room 751.
All responses are due by June 10, 2014 at 2:00 PM CT.
Appendices
Appendix A - Requirements
The subsections below elaborate on the requirements a potential solution should accommodate but is
not an entire list of all functionality required.
Files and Metadata
Wisconsin’s transportation infrastructure project files, and the metadata kept about the files, must be
stored and readily available. This includes the following requirements:
For the Files







Able to store a wide variety of documents related to the design, construction, and maintenance
of transportation systems like highways, local roads, airports, etc.
Able to define new document types. Documents can be, but not limited to the types below:
ο Adobe formats: .PDF
ο Microsoft Office formats: .DOC/.DOCX, .XLS/.XLSX/.CSV, PPT/.PPTX, .VSD, .MPP, etc (not
email/Outlook .MSG at this time)
ο Text documents: .TXT, .RTF, ASCII
ο Pictures .JPG, GIF, .BMP, .TIF/.TIFF, .PNG, scanned images
ο Web: XML, HTML
ο Autodesk: CAD - Civil 3D: DWG
ο Autodesk: CAD - CAiCE: SRV
ο Bentley Systems: CAD – MicroStation: DGN
ο ESRI, GIS related: GDB, .KML, KMZ, .LDK, LYR, .MXD, MDB, .SDE, and shape file types
Able to handle data formats such as ASCII and binary.
Allow for documents to range in size from a few KB up to 5GB.
Able to have file and project names that include alpha, numeric and special characters.
Able to have paths of any size name we need.
Able to update, delete, and create directories including the ability to correct and change project
id changes in naming errors.
4/17/2014
8|Page
WISCONSIN DEPT. OF TRANSPORTATION
RFI 0508-DTSD – DTSD Interactive Engineering File Management System

Allow for files to be on a network share or local PC, and be private or shared. Files are large and
transporting them over the network can be slow.

Allow DTSD to note the existence and location of paper records that have not been imported
into an EDMS.
For the Metadata about the Files



















Metadata kept about the files is entered by staff or automatically captured. Information is also
kept about the relationships between the files such as workflow sequences, project groups, or
auxiliary reference files.
Able to automatically retrieve, view, and edit reference files. This is necessary for the
MicroStation application.
Able to opt not to have reference files displayed.
Allow the DTSD to define new document metadata.
Allow for numerous and a variety of document attributes (metadata). See metadata list under
Apependix B below.
Able to allow group names as they are now (work group designation that can be used for search
and for access control).
Allow for attribute [metadata] items "project contact", and multiple contacts, depending upon
roles: consultant, project manager, project supervisor, and primary contact. Currently there is
just one kept in PROJECT RESPONSIBLE USER ID.
Allow for attribute item "project account" (state project id, FOS ID, PS ID).
Allow for attribute item design file type.
Allow for attribute items: Owner, Updater, Seed file, Disable world read, Type project.
Allow for attribute item: "Comments section" (a fairly long description).
Some attributes must be in a strict naming standard/format, such as Project Names.
Able to edit existing file definitions for multiple files at once – example: "pp sheat" was defined
and renamed to "pp sheet” (often correction of text strings).
Allow for metadata to be filled automatically with items from separate files, i.e. the form with
attributes that DTSD has to fill in for Civil 3D files.
Enable enforcement required metadata, allow for optional metadata, and prevent entry of
superfluous metadata based on the value given for certain attributes. For example; when the
value of the Document Type attribute is “Construction” and the value of the Document SubType is “Structures,” the system will require the entry of a valid value for the Structure Number
attribute. Additionally the system should allow the entry of a value for the Contract ID attribute
but would not allow any entry of values for attributes not relevant for “Construction” and
“Structures” such as “Meeting Date.”
Able to easily configure enforcement of business rules as described above [for metadata] and
change rules as needed is a requirement of any DTSD document solution.
Able to define new document workflows that will be used for sets of approvals.
Able to route approvals and provide notices for day-to-day DTSD workflow as well as RDA
events.
An audit trail log is automatically maintained of the history of activities related to files and
projects during their lifecycles.
Search/Select
There is the ability to list and choose files based on the files’ attributes. This includes the following
requirements:
4/17/2014
9|Page
WISCONSIN DEPT. OF TRANSPORTATION


















RFI 0508-DTSD – DTSD Interactive Engineering File Management System
When executing the application’s functions, there will be the ability to choose on which file or
files the function is to be performed. The files can be selected and filtered on metadata. This
includes the ability to search and select subfolders.
Able to search for documents using one or more attributes.
Able to define new document search criteria.
Able to use wildcards to filter what is returned.
Would like to have a "Select all" option for whatever function is to be invoked. Furthermore,
the option needs two modes: 1) select the whole project folder and everything in it -or- 2) select
a subfolder under the project folder and select everything in that sub folder.
Able to configure project searches and choose what content is returned.
Able to search and report on a full description of a file or search on a partial description.
Able to search documents by content in addition to document metadata.
Able to search and retrieve document metadata file. This file will always be in the same sub
folder under the project (for DTSD, design projects) and could have the same file name. The
new system should find and retrieve this file so the document can be viewed and provides
information about the project and what is stored in it.
Able to save search criteria for future use, for both shared use and individual use.
Able to select files and directories, and view the resulting list before executing any procedure.
Able to select files and verify before executing any procedure.
Able to preview document, possibly via a thumbnail image.
Results of searches can exceed a significant number of entries, but should first display a warning
message.
Long descriptions are searchable and printable.
Search function that has the ability to search the full length of the item.
Able to sort file display order, i.e. ascending/descending order, or most recently modified.
Would be able to handle sub-directories when searching.
File Reporting/Display
There is the ability to select files for reporting the files’ chosen metadata and for displaying files with
and without redlined overlay. This includes the following requirements:
 Able to set up reports and project searches, such as print out metadata on certain project(s) and
search for files and report the files’ chosen metadata.
 Able to configure reports, and choose the content that is returned.
 Able to direct the output file to a default location or browse to a different location.
 Have choice of editor to display reports, i.e., Word, Excel, Notepad, etc.
 Able to toggle between create and print a report automatically.
 When report finishes executing, the report file opens automatically.
 Accommodate end-user reporting.
 Able to report on file types, archived files, archived projects, all projects, and able to report
when the project, sub folder, or file was last archived including last archive date.
 Able to report on work flow information.
 Able to report on audit trail information.
 Able to manage and display document redlining (markup overlay).
4/17/2014
10 | P a g e
WISCONSIN DEPT. OF TRANSPORTATION
RFI 0508-DTSD – DTSD Interactive Engineering File Management System
Move/Copy/Rename
Allow files to be duplicated, relocated, and renamed. This includes the following requirements:
 Able to move or copy a single file or multiple files.
 Able to set up rename rules, such as: user specified, keep same name, substitute characters,
replace leading character, drop characters, and auto sequence (next one comes up to be
renamed).
 Able to designate new rename rules that would substitute characters by location within a string.
 Have a rename function for files and projects that allow us to copy the file or project definition.
 Able to perform move, copy and rename functions on sub-directories. Want sub-directories to
be handled as subdirectories and not just additional characters in the name.
Versioning and Archive
Allow copies of interim versions to be saved and archived for later reference. This includes the following
requirements:
 Able to employ versioning.
 Use file versioning for most functions i.e. archiving history, and draft copies. Able to choose
from multiple versions with the default set to most recent.
 Able to perform versioning and archive on sub-directories included all associated files.
 Archive file and metadata for a version when checking in file, etc.
 Able to delete archived files, but retain the definition/metadata.
 Able to remove archive file and its definition.
 Able to UN-define or drop definitions and metadata of deleted archive files.
 Able to set archive rules, i.e. keep one, two or all versions of it.
 Able to set retention rules. Common retention periods for DTSD documents range from two to
30 years, and some documents are retained permanently.
 Able to have pre-defined file types with the option to customize.
 Able to import ASCII files with file definitions and file name.
 Accommodate the Wisconsin Department of Transportation’s (WisDOT) Record Disbursement
Authorizations (RDAs) requirement for mapping related documents to the applicable RDA
throughout the life of the document or file.
 Able to easily transfer documents to another agency. Many DTSD documents are turned over to
the Wisconsin Historical Society at the end of their lifespan.
Check In/Out
Allow users to quickly retrieve and store projects and files. To insure integrity of the projects and files,
restrictions are necessary for concurrent use of files. This includes the following requirements:
 Allow a single owner, and warn before overwriting files.
 Able to do Check In functionality such as:
o Check in: Move or copy file in work area to management system and delete record from
work area.
o Back up: Copy file to management system, but do not delete record from work area.
o Add new or update existing file definitions of files controlled by the file management
system.
4/17/2014
11 | P a g e
WISCONSIN DEPT. OF TRANSPORTATION











RFI 0508-DTSD – DTSD Interactive Engineering File Management System
The same project can have documents or files stored in different locations. Some will be stored
on the LAN; others may be temporarily stored on the local workstation when in use.
Able to define files and update them later. Set metadata and provide a drop-down menu with
default choices.
Able to import ASCII files with file definitions and file name.
Have pre-defined file types with the option to customize, i.e. if it is a 2D file, it defaults to that
option. Allow DTSD to set up associations between the extension designated in the files' name
and the file types.
Able to check in and import multiple electronic files and/or directories and inherit pre-defined
attributes. This ability is also needed for check out.
Able to do check out functions such as:
o Read: Copy file(s) in management system to designated area for read only.
o Write: Copy file(s) in management system to designated area for modifications and
locking the record (prohibiting others to edit) until the file is checked back in.
o Able to change check out mode from what was initially selected, i.e. read/write.
o Define: Update existing file definitions of files controlled by proposed management
system.
Able to checkout (copy) files to a different project.
Display at checkout which software version or release of MicroStation or AutoCAD created the
file;
Able to perform checkout on multiple files that were chosen via search by file name using a
wildcard;
Able to check out by subfolders;
Only one copy can be checked out for write at a time.
Access Control
Authorization to view and manipulate files is needed. This includes the following requirements:
 There is an estimated minimum of 500 potential users of the proposed file management system.
 Access can be role based, or rule based, or a combination of both.
 Able to configure application security similar to DOT standards.
 Able to integrate with Wisconsin’s Web Access Management System (WAMS) and Active
Directory (AD).
 Able to set up outside users. I.e. consultants.
 Able to hide files and designate files as "not to be copied" so they are not seen or copied by
others. This is needed for real estate and projects in early stages.
 Able to designate and customize varying levels of access. I.e. input, view, update, etc.
User Interface
Web browser access is desirable for the proposed solution for both internal and external staff. DOT’s
internal standard browser is Internet Explorer v10. This includes the following requirements:
4/17/2014
12 | P a g e
WISCONSIN DEPT. OF TRANSPORTATION


RFI 0508-DTSD – DTSD Interactive Engineering File Management System
The interface needs to be user friendly, have clarity and include intuitive help, tips and
instructions.
Clear, concise and understandable error messages are displayed when functions such as check
in, fail.
Interface with Other Systems
The replacement application needs to successfully interface with DTSD’s purchased and in-house
applications/systems. This includes the following requirements:
 An API/web service must be provided that allows other systems to store documents in the
proposed solution along with relevant metadata. The same business rules enforced by any
graphic interface to this system must be enforced with any integration point i.e. required
attributes and attribute value validation.
 Document retrieval via an API/web service must also be included.
 Allow for integration with existing WisDOT systems for validating and populating metadata and
RDA events.
ο Able to interface with purchased systems such as:
 Transportation infrastructure engineering software
 PeopleSoft
ο Able to interface with DOT’s in-house applications, such as:
 FIIPS (project financial management; client/server, mainframe, DB2)
 PMP (project management; web, Oracle)
 TUMS (utility management; web, GIS batch, Oracle)
 HAMS (highway access management; web, web mapping, GIS desktop and batch,
Oracle)
 HSI (bridge inspection; web, file storage, Oracle)
 ESubmit (electronic document transmittal tool)
 DOTView (interactive DOT data mapping tool; web mapping, Oracle)
A “Map Centric” interface to allow the user to pull up a map and use pan/zoom/identify
tools to drill down to a specific geographic area or highway segment and use that spatial
query to extract chosen information from the file management system
Administration
Allow some configuration of the replacement system. This includes the following requirement:
 Able to revise and reconfigure aspects of the application, such as defining metadata, defining
work flows, setting retention rules, some administrative functions, and access authorization and
security rules to accommodate the business as needs change.
 Able to delegate user administration to the business areas.
Migration
Migration assistance will be needed. This includes the following requirements:
 Able to transfer all files to the replacement system, including current and historical archived
data.
 Able to retain the current metadata items.
 Able to transfer metadata values and relationships to the replacement solution.
4/17/2014
13 | P a g e
WISCONSIN DEPT. OF TRANSPORTATION
RFI 0508-DTSD – DTSD Interactive Engineering File Management System
Appendix B - Metadata Items
Here is the detailed information about the metadata items to be maintained by any potential
replacement solution. There is no significance to text being uppercase:
Project Metadata
 Project number (substring value in PROJECT SHORT DESCRIPTION, variation C)
 Project ID - An eight digit number indicating what project the document is for. Multiple values
can be provided for some documents. This value could be validated against an existing WisDOT
system/Database that contains all valid project IDs. A project can be associated with multiple
project ids. These "sub-projects" can be of different project types. Design, Construction,
Railroad, Real Estate, and Utilities all use an eight digit number.
 PROJECT ACTIVE PURGE – How the files archived within this project are to be treated. Possible
values are: DELETE ALL BUT THE LATEST ARCHIVE COPY, KEEP ALL ARCHIVE COPIES, AUTOMATIC
MOVE TO TAPE OF NON CURRENT COPIES, AUTOMATIC MOVE TO TAPE AFTER SPECIFIED TIME.
 PROJECT CREATE DATE – The date the project was initially created (in IBM format).
 PROJECT DEFAULT PROTECTION – Series of switches for specifying READ, WRITE, EXECUTE,
AND/OR DELETE AUTHORITY. There are four switches for the OWNER, the OWNERS GROUP, the
rest of the WORLD, and the OWNERS BUREAU, DIVISION, AND DEPARTMENT.
 PROJECT DIRECTORY – The directory to be used for this project when files are checked out to
the PROJ CKOUT_NODE_NAME.
 PROJECT LONG DESCRIPTION - A detailed description of the PROJECT. THE user may choose to
format this area to contain specific data. If so, this would be an OWNER RESPONSIBILITY.
 PROJECT SHORT DESCRIPTION, variation A - A SHORT DESCRIPTION OF THE PROJECT. (variation
B and variation C have content split up into multiple items, which may present conversion
issues)
 PROJECT SHORT DESCRIPTION, variation B - Group of search fields, as per District-4. These
substrings may present conversion issues. Their substrings are listed separately.
 PROJECT SHORT DESCRIPTION, variation C - Group of search fields. These substrings may
present conversion issues. Their substrings are listed separately.
 PROJECT NAME – The name of the project. This will be used to reference the project rather than
the UNC. This is the highest level of organization. ("Embedded" project name prefixes have
specific meanings are used in filter selections.)
 Project Limits (substring value in PROJECT SHORT DESCRIPTION, variation B)
 Project name or limits (substring value in PROJECT SHORT DESCRIPTION, variation C).
 Type of Work (substring value in PROJECT SHORT DESCRIPTION, variation B)
 PROJECT TYPE – The type of project; the full list of values to be decided. JF: this is a onecharacter metadata item whose value can be anything the person wants.
 Project type (substring value in PROJECT SHORT DESCRIPTION, variation C)
 Estimate Date – A date value. (TG: Date during the design phase.)
 Construction Year – A four digit year.
 Construction Year (substring value in PROJECT SHORT DESCRIPTION, variation B).
 Solicitation Date – A date value (date sent out request for proposals)
Reference Numbers/Codes Metadata
 Contract ID – An alphanumeric value (up to 15 characters) that ties a document to a specific
contract. This value could be validated against an existing WisDOT system/Database that
contains all valid Contract IDs.
4/17/2014
14 | P a g e
WISCONSIN DEPT. OF TRANSPORTATION





RFI 0508-DTSD – DTSD Interactive Engineering File Management System
EPA Number - An alphanumeric value (up to 20 characters) that records the EPA Number
associated with a document.
Docket Number – An alphanumeric value (up to 20 characters) that records a docket number for
applicable documents.
Permit Number – An alphanumeric value (up to 15 characters) that records a utility’s permit
number for applicable documents.
Work Order Number – An alphanumeric value (up to 20 characters) that records a work order
number for applicable documents.
PROJECT ACCOUNT CODE – The default account code to charge to all terminal and computer
resources when working on files in this project.
Involved Parties Metadata
 Prime Contractor – A text value (up to 65 characters) that contains the name of the contractor
for applicable documents. This value could be validated against an existing WisDOT
system/Database that contains all valid WisDOT contractors.
 Property Owner – A text value (up to 65 characters) that records the name of the property
owner for applicable documents.
 Company Name – a text value (up to 65 characters) that contains the name of the company for
applicable documents. This value could be validated against an existing WisDOT
system/Database that contains all valid WisDOT company names.
 Scope Notice of Interest (NOI) Type - A value pulled from a predefined list.
 Tribe Name – A text value (up to 65 characters) that records the name of the Native American
tribe associated with a document. This value could be validated against an existing WisDOT
system/Database that contains all valid tribe names.
 PROJECT OWNER – The organization that owns the project.
 PROJECT RESPONSIBLE USER ID – The user ID of the person responsible for this project. This is
the contact individual for questions or problems about the project content.
 PROJECT UPDATE GROUP – The identifier of the group of persons that can update the project
definition and the files in the project.
 TRANSACTION USER ID – The user identifier of the individual running this transaction.
 FILE LAST CHECKOUT USER ID – The user ID of the person who has checked out the file.
Place & Features Metadata
 Region – A value pulled from a predefined list of 8 offices (5 regions) that comprise Wisconsin.
 County – A value pulled from a predefined list containing the 72 counties in Wisconsin. The
values in this list could be pulled from an existing WisDOT system/Database.
 Route – A combination of Route Type and Route Number. The Route Type is a value pulled from
a pre-defined list and the route number could be 3 characters as entered by a user.
 Geographic Location – A text value (up to 150 characters) that describes a location for applicable
documents (i.e. “this picture was taken 200 yards south of bridge 212”). This is a geographic
location, not an electronic data location.
 Georeference – A reference value that indicates a geographic position, such as latitude &
longitude or xyz coordinates, is desirable.
 Structure Number – An alphanumeric value (up to 10 characters) that identifies structures such
as bridges.
 Crossing ID – An alphanumeric value (up to 10 characters) that identifies a railroad crossing.
4/17/2014
15 | P a g e
WISCONSIN DEPT. OF TRANSPORTATION










RFI 0508-DTSD – DTSD Interactive Engineering File Management System
Parcel ID – An alphanumeric value (up to 10 characters) that records a parcel ID for applicable
documents.
Intersection – A text value (up to 65 characters) that describes a location of an intersection for
applicable documents (i.e. “SW corner of Water Street and 5th street”).
Utility Number (Parcel Number) – An alphanumeric value (up to 20 characters) that records a
utility’s parcel ID for applicable documents.
Municipality – A text value (up to 65 characters) that records the name of municipality for
applicable documents (i.e. “Hales Corners”).
Spatial location - GPS coordinates or other coordinate systems.
Highway Project is on or near (substring value in PROJECT SHORT DESCRIPTION, variation B)
County or Counties project is in (substring value in PROJECT SHORT DESCRIPTION, variation B)
County or counties project is in (substring value in PROJECT SHORT DESCRIPTION, variation C)
District number, A for airport, or RR for railroad (substring value in PROJECT SHORT
DESCRIPTION, variation C)
Highway project is on or near (substring value in PROJECT SHORT DESCRIPTION, variation C)
File/Document Metadata
 Document Type - A value pulled from a predefined list of document types.
 Document Sub-type - A value pulled from a predefined list of document sub-types.
 FILE TYPE – Indicates the kind of file such as text, binary, DESIGN2D, DESIGN3D, CELL-2D, CELL3D, ETC.
 Draft/Final- a Boolean value.
 Sent/Received Date – Date value indicating when a document that is a correspondence was sent
or received.
 Description – A text value (up to 150 characters). The team wants a longer value.
 FILE DESCRIPTION – A textual description of the file and its contents.
 Amendment Number – An alphanumeric value (up to 5 characters) that records the amendment
number associated with a document. Allow for up to 20 or so amendments.
 Cataloged/Un-cataloged - a Boolean value.
 ARCHIVE FILE LOCATION – An indicator of how and where the file is currently stored. The values
include FORCED MIGRATION, ON HOST DISK, IN ASM2 ARCHIVE, IN DEEP ARCHIVE.
 ARCHIVE FILE FORMAT – The format of the archived data set. Permitted values are 'B' FOR
BACKUP AND 'C' FOR COPY.
 ARCHIVE FILE SIZE – The approximate size of the file in kilobytes.
 CHECK SUM - The 16 BIT CHECK SUM For the file SFNAME; used to validate between computer
systems.
 FILE CHECKOUT – The checkout status of a file/ Possible values are: FILE IN, FILE OUT FOR READ,
FILE OUT FOR WRITE, FILE DOES NOT EXIST (FORCED MIGRATION), FILE CREATED BY
CONVERSION.
 FILE DEVICE NAME – The name of the device to which a CADDS project file has been checked out
to.
 FILE NAME – The name of the file when it was first created. Normally this is the name on a VAS.
This does not include the DIRECTORY, NODE OR DEVICE.
 FILE NODE – The name of the machine that the file has been CHECKED OUT TO.
 PROJECT DESIGN FILE EXTENSION TYPE – The file types that are design file format. The defaults
are DGN AND CEL
4/17/2014
16 | P a g e
WISCONSIN DEPT. OF TRANSPORTATION



RFI 0508-DTSD – DTSD Interactive Engineering File Management System
SUFFIX FILE NAME – The name excluding path that the file PNAME_FNAME has been assigned
for storage of the file on a file server.
Asbuilt Folder or File (substring value in PROJECT SHORT DESCRIPTION, variation B).
CADD file format/version(s) (V7, V8, DWG, etc) (substring value in PROJECT SHORT
DESCRIPTION, variation C) (For file content created by MicroStation, AutoCAD, etc.)
Project/File Processing Metadata
 Sent/Received – A Boolean value indicating if a correspondence document was initiated by
WisDOT or received by WisDOT.
 ARCHIVE FILE ARCHIVED DATE – The date and time that the file was created on the host system.
This does not change as the file moves to or from the ASM2 archive. The format is IBM SYSTEM
TIME DATE.
 ARCHIVE FILE LAST UPDATE DATE – The date and time that the file was last maintained on the
host system. This does not change as the file moves to or from the ASM2 archive. The format is
IBM SYSTEM TIME DATE.
 FILE CHECKOUT NODE – The NODE or computer that sent this transaction.
 FILE TRANSFERRED FLAG – This flag is set when a file transfer is taking place. The FLAG is
removed when the transfer is successful. A query on this FLAG will point out files that a transfer
was begun but never completed.
 FILE LAST UPDATE – The date and time that this record was last updated. This is used to
preempt update transactions as required. Date time is in IBM format.
 FILE TRANSACTION TYPE – What the user was doing to t a file. Possible values are: DEFINE FILE,
TRANSFER FROM CONVERSION DATA, CHECKOUT FOR READ, CHECKOUT FOR WRITE, CHECK IN,
DELETE FILE, ARCHIVE TO DISK, ARCHIVE TO TAPE, SEARCH FOR FILES, NO ACTIVITY, FORCED
MIGRATION TO DISK ARCHIVE, FORCED MIGRATION TO TAPE ARCHIVE, UPDATE FILE
INFORMATION, RESTORE FORM BACKUP.
 NEXT SEQUENCE NUMBER – The next value to be used when generating SFNAME from other
data. This field is used to be sure the combination of PNAME, FNAME, AND SFNAME is unique.
 Year photography was flown (substring value in PROJECT SHORT DESCRIPTION, variation C).
 Storage box number(s) where material stored (substring value in PROJECT SHORT DESCRIPTION,
variation C)
 PROJECT TRANSACTION TYPE - WHAT THE USER WAS DOING ON THE PROJECT or File. This is a
system created one-character value (no user input) that is used for audit trails. Currently 18
POSSIBLE VALUES ARE letters A though S, to pre-present such transactions as: CREATE PROJECT,
UPDATE PROJECT, READ PROJECT DATA, NO ACTIVITY, Delete file from archive, etc.
 PROJECT UPDATE DATE – The date time stamp detailing when the last update has occurred to
CADDS project information for a specific CADDS project. Date time is in IBM format.
 TRANSACTION DATE – The date and time that this entry was made in the TRANSACTION LOG.
 TRANSACTION STATUS – Did the transaction complete successfully?
4/17/2014
17 | P a g e