Comments
This is a menu of the topics on this page (click on any): Leo Letendre Hugh Moore Lynn Hazlewood .
The following comments were received on 3/7/02 and are about the RFP as reduced to include only the conversion of APL data to text files. Revisions to the page called "files.htm" have been made in response to these comments. Further discussion can be had by e-mail or telephone if it appears that I have not been responsive to some comment. (Carl House, 3/7/02)
Leo Letendre
1) You mention the fact that there are 8400 files and then later list a
number of them much smaller than 8400. Maybe a bit more on the hierarchy of
the file system would be useful.
2) In a similar vein, if you are expecting the conversion to be automatic, that is start it up and walk away, you need to let people know how they can determine what type of file a given file is. That is, what handles are available as one courses through the directory structure to determine if the file contains Top Ten data, pictures, records, etc.
3) You give an example of how a Top Ten file is named yet the file name given for the Top Ten files (e.g. file name= f4211.sf) doesn't conform to the rules.
4)Do you expect files containing images to be converted to something? You list them at the end of the RFP but you really don't address them in the body of the text.
5) You use a few terms which are either APL specific or are not commonly used (any more?) such as FCN. You might want to mention what they are and why they are useful.
6) You say "Relays are probably same as received from R&T, but should be provided for." The final RFP should be specific and not leave any uncertainty on our part.
Just some quick thoughts. Keep on plugging!, Leo Letendre
Hugh Moore
I'm impressed. You did some fast work on the revision. Here are my
comments:
The RFP states "The structure and scope of USMS digital archives will not change during the several months required to develop an enterprise database strategy, though data will be added within the current scope and structure."
This seems to imply that we will be changing the structure in the future. That's not surprising. However, we're wasting our money unless we develop a plan so that such changes can easily be incorporated in the new "export tool".
Be careful when using the word "should". "Should" is not binding. If possible use the word "shall". Examples: "Data currently stored as text vectors should become .txt files. Data stored as matrices with fixed width fields should become .csv (comma delimited files -- the data contains no commas). " If we want to mandate the "requirement" we need to use "shall".
The RFP states "Some level of documentation will be needed to enable others (non-APL people) to use the text files. Perhaps a catalogue in both digital and paper format is desired, but it may not be necessary if folder structure and file names are sufficient to provide documenation. The proposal should consider this." I don't think that we should put the burden of documentation on the bidders. It appears that you have done a great job of defining the structure. I think that we can assume that anyone importing the data into a data base application will not need any information beyond the file definition that you already provided.
The RFP also states "The proposal should also consider how we can be assured that the text version of the database includes all of the data items in the APL version. Control should be provided for on the number of items and on some sort of "checksum". " I think that we may need to "brainstorm" this a little. Since you already list the number of records and file size, I'm not sure that a checksum will buy us much since I'm not sure how the bidder can checksum the existing data.
I'll spend some more time looking at the RFP tomorrow morning.
Hugh Moore
Lynn Hazlewood
Thanks for getting the changes requested by the EC done so quickly. I
have a few comments on your RFP:
1) In the paragraph where you describe the deliverables, I think you should be more specific. It requests the text format files and this is OK. However, you say the export procedure should be automated so it can be repeated. You don't say they have to also deliver the programming that accomplishes the export procedure. Conceivably, they could charge us to redo the export each time we need to do it.
2) I would like to see more specifics on the output side of the equation. For example, you describe the current file names and formats in detail, but do not specifically give the file names and formats (with examples) for the output (you imply this). You have a somewhat indirect way of expressing things and this is OK for those of us who know what you're talking about. I am wondering if someone looking at this cold will be able to follow your meaning and deliver exactly what we're looking for.
3) You do not say that the bidders will be able to examine the APL files before they submit their bids. They will have to have some way of determining what the conversion issues will be when they put a price on it.
4) I'm somewhat uncomfortable about the documentation issue. We should specify the documentation we're looking for.
5) In what form will we be presenting the RFP? Is this to be a stand-alone document delivered in hard copy or PDF format? The reason I ask is, there is a lot of information on the web site that is not part of the RFP. By following the various links from the main RFP page, you can get into these other areas. I think we need to focus the bidders' eyes only on the RFP. You could add an appendix that points to the other information, but the demarcation of the actual RFP should be clear.
6) Do we need to include information on the bid evaluation and contract administration process in the RFP? Would this impact how bidders respond?
Hopefully, we can clear up these questions and any other people may have quickly so we can get to the actual bidding process. Thanks for all your hard work. --
