Document the results fo the Math archive structure discussion on thrusday

We converged on a design that is inspired by the one in #1, i.e. with a top-level struture

build 
export 
  comp
  data
  ded
  narr
  rel 
meta-inf
source

• buildis a subdir, where the build process can deposit unspecified intermediate files that are worth keeping, since they are expensive to build

• export contains the main payload of the math archive. It has subdirectories for each of the tetrapod aspects:

  • comp for computation, typically programs or program fragments
  • ded for deduction, typically proofs
  • narr for narration, typically text fragments or document structure fragments (e.g. sections, chapters, ...)
  • data for concretizations, concrete data, typically sequences, matrixes, time series, ...
  • rel for relational data, usually RDF triples jointly describing a graph.

  All these directories (except rel) contain files with data blobs, which are accessible by a key that is usually a MMT URI, encoded in a known encoding, e.g. XML, JSON, OpenMath, ... The directories also contain a standardized metadata representation that keys and encoding format to file names. There may be intermediary directories that help the file sytstem subdivide the name spaces, if there are extremely many blob files; in this case the mapping above is from keys to file paths. The rel directory contains collections of triples in some known representation.

• meta-inf contains meta-information just like the current math archives

• sourcecontains the source files. There is no restriction on what goes here, only that the build process has to eb able to cope with them. For what we have in mind for sTeX, see #1. In MMT we have .mmt source files.

Generally, the contents of the export directory should be a lossless copy of the source folder (where "lossless" means "up to irrelevant stuff". If there are leftovers, we need a way of treating them.

The general guideline for designing the build system (and the format of the export folder) is that the latter should store any results of the build that are more expensive to re-create than to store and/or transmit. cc: @all