title: architecture of skdb

main concepts:
- packages:
    - metadata:
        - each package has a dependency set, a list of other packages that must be downloaded in order to make the package work
        - in the metadata the dependency set is not a list but rather a hierarchical boolean tree
    - source or catalog data
    - CAD files
- dependencies:
    types:
        build:
            description:
                if Y must be used to make the part X
                then X has a build dependency on Y
                #note not all dependencies are parts (but they must be a package)
            examples:
                - a screw has a build dependency on a lathe
        assembly: comes after the build process; integrates component parts into an assembly part
        disassembly: undoes the steps in assembly process; decomposes assembly part into components           
        use: &use
            description:
                if part X is unusuable when without Y
                then X has a use dependency on Y
            examples:
                - a screw requires a nut in order to fasten something else
        run: *use
        software:
            description:
                if the skdb representation of X is unusuable without the skdb representation of Y
                then X has a software dependency on Y
            examples:
                - library header files required for compiling support into another program
                - precompiled object or shared library for link time (i.e., package X requires a shared library from Y if you compile package X)
                - precompiled object or shared library for software run time (i.e., package X loads up the lib.so file (not compiled in))
    dependency sets:
        each package has at least one dependency set that must be satisfied (in special cases that one set can be null)
        without satisfaction of a dependency set, the package is probably useless (a broken install)
        a package with multiple dependency sets allows there to be unique buildtime, runtime and software dependencies for different situations
        for instance, certain buildtime dependencies might demand certain runtime dependencies
- instructions:
    description:
        sequences of steps for humans and machines for any of the different scenarios (build, run etc.)
        usually generated by running instruction generation code from each of the dependencies
    wishlist:
        - zoomable text detail: see doug engelbart or code folding
        - 3D animation:
            description: see 'parameterized action representation' papers for neat diagrams
            url: http://adl.serveftp.org/papers/instructions/Virtual%20humans%20for%20validating%20maintenance%20procedures.pdf.1.png
        - 2D: see lego instructions
        - sentence planner: &spud
            - generate different sentences that say the same thing given the same input #for disambiguation
            - English grammar
            - other natural languages
            - tree-adjoining grammars: xtag
        - virtual human actors to verify and demonstrate instructions
        - virtual non-human agents to verify and simulate actions (robots, machinery)
    concepts:
        - Agent:
            - such as a cnc machine, human, computer, something else
            - its methods are actions that build scripts can select from
            - is a lathe a Part or an Agent?
        - Tree:
            - top-to-bottom
            - root state is at the bottom
            - root is the last visited or last added state
            - if you were to make a pie, the root node of the recipe tree would be a State with a Pie in it
            - when you make a pie you need merge the root state (node) from two trees:
                crust making tree:
                apple slicing tree:
        - State:
            - a node in the tree
            - contains a list of various objects, maybe a Pie, maybe a Part, etc.
            - has an __iter__ method
        - Action:
            - an edge in the tree
            - defined as a method of a particular actor
            - no specific sequence of actions unless necessary; step-by-step
              instructions are just a particular (optimal) serialization of action dependency tree
    questions: #and answers, if you're lucky
        - where are steps (in instructions) written down in skdb?
        - how do you translate from an action to machine code:
            - CAM has a "post processor" which tailors the generic instructions for the individual machine tool/language
        - or natural language: *spud
        - how do instructions from other packages contribute to instructions for dependent packages?
    external references: see f16 maintenance manuals (internal fuel tank vent)