Use Documenter.jl for documentation

[jpfairbanks]

We should use the documentation generator https://juliadocs.github.io/Documenter.jl/stable/man/guide/ for the docs in this package.

[jpfairbanks]

the last step is to enable publishing.

• [X] enable travis
• [x] Add .travis.yml
• [x] add secret key to travis
• [x] add deploydocs
• [ ] add gh-pages branch

[jpfairbanks]

Our travis builds take longer than 10 minutes... which will make this hard.

[jpfairbanks]

We need to either reduce build time, or host our own CI infrastructure.

[jpfairbanks]

@mehalter has gotten travis builds to be successful. The last step is to get the autodeploy of docs.

[infvie]

Doc fixes : Intended Use Cases

• Intro
  • latex rendering issue?
• Answering Counterfactual
  • the numbering for this is off
• Instrumenting Model Code
  • include Lotka-Volterra population dynamics latex

[infvie]

Doc fixes : Approaches

• almost none of the citations or hyperlinks are working : why are none of these rendering?
  • really bad in EpiModels Example
• Information Extraction
  • no talk of caching
  • Personally, I feel one of the strongest points of this project is that we can store huge graphs locally, and scientist can easily use this pre-made corpus, but there is literally no mention of this.
• to me Data Sets in the Knowledge Graph makes more sense in the context of info extraction
• The scheme.org section expresses/justifies why this project was started which is to fill a gap for what is not available currently => should be more in a "Why semanticmodels?" section - better story-boarding
• Types
  • need to include cassette give them the "bleeding edge of the bleeding edge of the bleeding edge" speech
  • i dont feel like enough credit is given to the julia base with macros and exposure we have to lowered code

[infvie]

Doc fixes : dubstep

• Computer langs by nature are designed to be mnemonic
  • why were TraceCtx & LPCtx chosen?
  • assumed knowledge of overdub

[infvie]

1. Collect a sample of known “good” inputs matched with their corresponding “good” outputs, and a sample of known “bad” inputs matched with their corresponding “bad” outputs.
   • “Good” here is defined as: given these input(s), the model output(s)/prediction(s) correspond to expected or observed empirical reality, within an acceptable tolerance/range re: error.
   • Edge cases to note but not heavily consider @ this point:
     • For “good” input to “bad” output, we just corrupt the “good” inputs at various points along the computation.
     • If assumption that code is correct and does not contain bugs holds, then it is ok to assume we will not observe “bad” input to “good” output.
2. Run the simulation to collect a sample of known good outputs.
3. Instrument the code to log all SSA assignments from the function calls
4. Train an RNN on the sequence of [(func, var, val)...] where the labels are “good input/bad input”
   • By definition, any SSA “sentence” generated by a known “good” input is assumed to be “good”; thus, these labels essentially propagate down.
5. Partial evaluations of RNN give you the “where did it go wrong. Instead of,