Summary workflow (blocker)

[valentinedwv]

• Document summary workflow, and incorporate into geocodes documentation.
• migrate cleaned up summary code to a repository (geocodes, or new repo)

specifics:

• https://github.com/earthcube/geocodes/blob/f01bd917fe29d5d7e158ca60e7539f93e388c8e2/docs/setup_indexing_with_gleanerio.md?plain=1#L381
• somewhere in the tenant setup: https://github.com/earthcube/geocodes/blob/f01bd917fe29d5d7e158ca60e7539f93e388c8e2/docs/tenant/index.md?plain=1#L22
• and add to loading production data: https://github.com/earthcube/geocodes/blob/main/docs/production/creatingAndLoadingProduction.md?plain=1

[MBcode]

cleaning up and documenting it more now, will get in shared place soon, linked from this issue

[MBcode]

starting diagram / documentation of summary workflow https://github.com/MBcode/ec/blob/master/summary.md

[MBcode]

The 1st part of getting a crawl uses a workaround to get quads/repo for the summarization

[valentinedwv]

So, we need to add a note not to disable to milled:true to the doco

I was thinking about disabling the default templates for glcon configuration no longer run milled gleaner, because Nabu loads the data to the graph.

[MBcode]

btw the fix_runX.sh process can take summoned as well, it just takes longer; then it makes the quads, and now materialize_summary.py takes the repo.nq to repo.tll for uploading. Just for safety sake, I think it is best to upload both of these files, to make sure the graph-urns are exactly the same btwn them. The latest PR gets this all going w/blaze vs fuseki, and later we still have the option of query of file via lib vs using any endpoint at all

[valentinedwv]

complete on dev https://github.com/earthcube/earthcube_utilities/tree/dev/summarize