The first meeting of the design group made some initial design decisions and discussed several issues which have not yet been resolved.
We also managed, after several discussion involving all the participants and then the design group, to decide on copyright and licensing. A summary of our copyright and license decisions are located here.
Basic structure of the database
Data storage
- Data resides in directories. Top level: Readme.txt, and subdirectories for: data, optional code used to generate the data, and optional papers/references. One should be able to navigate these directories and manually grab files with a browser.
- The Readme.txt file describes the contents: the format of the data and what data is in a particular file. It should also contain at the top, in a way that can easily be indexed and searched, info on: who created the data, what machine(s)/OS/code was used, when it was created, how long it took to run, and the level of rigor and precision of the computation indicated.
- The Readme.txt file should explicitly indicate what data is in the data directory. Except for updating the description of listed data as more data is uploaded, the Readme.txt should not routinely be changed. In particular, changing the format of the data files is strongly discouraged.
The data files
- Data files should (usually) be "easily machine readable ascii files."
This can, but not always, mean that:
- The data files usually have one entry per line, with fields separated by single spaces (not commas), there is no markup or documentation in the data file.
- The file name and the associated readme file determine the contents of the file.
A simple data directory with zeros of the derivative of the zeta-function is at http://aimath.org/~farmer/testdata1/
A more complicated example with eigenvalues of Maass forms is at http://aimath.org/~farmer/testdata2/ (needs to be modified again to reflect design changes)
Procedure for upload:
1. login (register by giving email address and then confirming)
1. online form: upload local tar file or give url to a tar file.
Want:
- ability for the uploader to modify data and other directories. revision control of the readme. readme should be changed, afterall, to reflect changes to the data.
- changelog for things like fixing errors.
- talk page
- as much revision control as possible.
- uploader goes to wiki and puts a link, provided by the server, to the uploaded data.
directory structure:
- description file
- data
- code
- papers
- autogen/ sqlite, revision control etc
- strong opposition to polluting uploaded directories (data, code, papers) etc with any files such as svn files.
In the description file, uploader provides a name for the data (ex Stein-Watkins BSD data). Our server provides the directory name/identifier for storing.
The description file has structured data for author, when created, etc. If the uploader wants the data to be read into a database, then the description of the fields in the data files must also be in a structured format.
References should be in the form Title, identifier number, the 'L-function and Modular Form' database.
A picture of the whiteboard at the end of the design discussion on Day 4 (Thursday) of the workshop Aug_2_Design_group_Whiteboard_pic.jpg
